Generate version alias info to streamline updates

[roberth]

When the version bounds change, so do the attribute names, which leads to busywork such as most of the commits in

• haskellPackages.releaser + other fixups nixpkgs#266708

Proposal

For every configured version bound, figure out a minimal identifying suffix.

Alias

For each such suffix, add an alias such as

  Cabal_3_10_x = self.Cabal_3_10_2_1;

Suffix

Minimal identifying suffix examples:

2.*    => _2_x
<3.0   => _2_x      # usually works, but weird if it points to a 1_x version; might want to check
>=1.2  => _1_2plus

Generic override

To really solve the problem, we need to take care of attribute definitions as well; the left hand side of the attribute =.
A possible solution is to also generate in the package set:

  versionAliases = {
    Cabal = {
      "Cabal_3_10_x" = { version = "3.10.2.1"; aliasOf = "Cabal_3_10_2_1" };
      "Cabal_3_10_2_1" = { version = "3.10.2.1"; };
    };
  }

This allows a function to be written that applies overrides to all aliases, or a version range.

# configuration-common.nix (for example)
{ pkgs, ... }:
# ... as usual

self: super:
{
  # ... as usual
}
// super.overrideRange "Cabal" { atLeast = "3.8"; lessThan = "3.12"; } (Cabal:
    # do anything you would do in a normal overlay attribute value here
    # using the compose style library, you may even eta reduce this lambda, yay!
    addBuildDepends [ self.hspec_2_11_x ] Cabal
  )
// super.overrideAll "hspec-discover" (super.generateOptParseApplicativeCompletions ["hspec-discover"])

Though probably we should use composeExtensions to avoid accidentally overwriting things in the attrset before the dynamic overrides (perhaps only for the first //, or the design could be adapted; see below).

In an overlay, it is acceptable for attrNames of a layer to depend on super; just not on self. attrValues may always refer to self, as usual. So I expect no strictness problems with such a design.

Improved interface:

# configuration-common.nix (for example)
{ pkgs, ... }:
# ... as usual

haskellLib.versionRangeOverrides (self: super: {
  # ... as usual
})
{ "Cabal" = [
    { atLeast = "3.8"; lessThan = "3.12";
      modify =
        self: super: Cabal: addBuildDepends [ self.hspec_2_11_x ] Cabal;
  ];
 "hspec-discover" = [ { modify = self: super: super.generateOptParseApplicativeCompletions ["hspec-discover"]; } ];
}

This allows versionRangeOverrides to use composeExtensions once, and compose the dynamic part in a single concatenation using concatMapAttrs instead of many //.

[cdepillabout]

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?

[maralorn]

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

[sternenseemann]

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 latest library doesn't pull in other latest library #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.