Generate version alias info to streamline updates about cabal2nix HOT 3 OPEN

I have also thought multiple times about having Cabal_3_10_x or Cabal_3_10 or also Cabal_latest.

from cabal2nix.

I think there are a couple of problems with this kind of stuff.

• It of course will increase file size a lot, especially if any kind of expectation about the presence of these attributes is introduced.
• The question is how far we should go with this. Should we solve #568 as well? hackage2nix seems slow enough as it is already…

I remember @peti usually replying that how cumbersome working with non-standard version is partially intentional. It should be a last resort if it is not possible to get the desired package(s) to build otherwise. Usually the busywork can be solved by a very simple search and replace on nixpkgs (I use amber). With fancier attribute semantics this may stop being possible.

OTOH it seems to me that the amount of versioned overrides necessary has increased which is pretty infuriating. With increased activity on core tools like cabal-install liberal version constraints have kind of fallen overboard. I'd also guess that the death of cabal hell thanks to the new style cabal builds has made supporting Stackage LTS less of a priority.

from cabal2nix.

I agree that when version bounds change, we have to do a lot of busy work. It is really annoying.

I like the idea of having additional attributes for packages, like the proposed:

  Cabal_3_10_x = self.Cabal_3_10_2_1;

As you may know, a year ago or so we added aliases for ghc versions, so now attributes are available like haskell.packages.ghc92, which would be an alias to haskell.packages.ghc928 (or whatever the latest GHC-9.2 version is at that time).

I'm wondering if you could be more specific about how you'd expect the Nixpkgs Haskell stuff would change, as well as hackage2nix (which I think you're implying would have to change).

For instance:

• Would the pkgs/development/haskell-modules/hackage-packages.nix get a bunch of additional attributes?
• hackage2nix would be responsible for generating these? (it sounds like you may be suggesting that these attributes would take a non-standard format, and potentially live in a different file)
• What sort of algorithm would hackage2nix use to figure out what additional attributes? It sounds like you're suggesting that the version ranges required by packages depending on package foo should be used to determine which attributes to generate for package foo.
• Users sometimes complain that the Haskell stuff in Nixpkgs is "too big". How many additional attributes would there be in practice? Would these additional attributes have some negative affect on space or performance?

from cabal2nix.