Handling patched packages about cabal2nix

[peti]

It is true that the "re-generate in place" approach was extremely useful during development of the tool chain, but nowadays, it's less important simply because there are hardly any packages left that have non-standard patches:

$ hackage4nix -v pkgs/ 2>&1 | grep ^ignore | grep -v non-cabal
ignore non-hackage package pkgs/development/compilers/flapjax/default.nix
ignore known bad package pkgs/development/libraries/haskell/haskell-platform/2011.2.0.1.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2011.2.0.0.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2010.1.0.0.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2009.2.0.2.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2010.2.0.0.nix

Of course, this doesn't mean that we won't have more packages that need patching in the future.

[peti]

After some more thought, I realize that I may have misunderstood what you meant. Do you suggest parsing flag assignments out of the existing Nix expressions instead of hard-coding them in cabal2nix?

[kosmikus]

After some more thought, I realize that I may have misunderstood what you meant. Do you suggest parsing flag assignments out of the existing Nix expressions instead of hard-coding them in cabal2nix?

Exactly. I always thought we'd move to configuration files. But then
we'd have to store the config files. So why not use the existing
expressions as configuration? Perhaps it's a bad idea, and I'm not
fully convinced, but it's a suggestion as a basis for discussion.

[peti]

After more thought, I am still unable to make up my mind how I feel about this change.

If we'd parse flag assignments and extra configure parameters out of an existing expression -- rather than having a hard-coded list --, it means that cabal2nix won't know about these settings anymore. That's probably no big deal. In practice, I hardly ever run cabal2nix. I only use it to add new expressions, and those won't have any custom configuration defined anyway, so there is no loss of functionality.

The advantage of this approach would be that people can improve existing expressions (i.e. by adding flags) and commit their changes into the nixpkgs repository, rather than having to worry about the cabal2nix source code. That is a nice feature.

Of course, the parser would have to be pretty smart, especially if we ever get to the point where Cabal flags are supported in the generated expression in the way discussed in issue #6. In fact, if the functionality described in that issue would be available, then there wouldn't be a need to deal with Cabal flags at all in cabal2nix -- we could deal with that subject entirely in haskell-packages.nix, which feels like the superior approach.

I dunno ... I guess, I am undecided. :-|

[peti]

I guess it's probably safe to close this issue. It's been inactive for 3 years, and there's no immediate effort underway that touches this subject in any way.