Another package that definitely should have a maintainer.

It is maintained by couple of people already - one reason I've asked if multiple maintainers per package are allowed but this one (and related) could possibly have @haskell-nix listed as a maintainer (which I'm intentionally pinging here to see who actually gets the ping, sorry for the noise).

Oh, I am sorry. I take that back. I thought it had been broken for a while, but it only broke last night. So there wasn‘t even a maintainer ping yet.

ping @NixOS/haskell are you guys happy with this direction? Alternatively we could override relude and semialign hnix takes to newer versions, but I'm not sure if that could cause trouble with propagation.

I share your concern that it will be annoying for downstream users if we override.

Arrived too late to the party.

@sternenseemann Thanks 🥳.

#122706 (comment) & #122706 (comment) It is interesting, since my main strategy always to go to use overrides. See it as design & package stores misalignment & that out of Stackage line overrides can be handled in an automatic manner someday.

#122706 (comment)

@sorki - Somehow notification did not arrive. Checked the settings, settings everywhere seems Ok and allow those notifications.

You are a member, I am a member - no notification - weird. Internet so far did not provided info. I receive Zero Hydra Failures group team mentions, but not Haskell-Nix, bummer, need to figure that one out.

This sort of backporting patching seems interesting.

I share your concern that it will be annoying for downstream users if we override.

I do not understand why. Please, @maralorn, can you help understand why?

Not users using the hnix binary.

But users who try to build a project that relies on two different libraries, where both use different semialign versions with nix.

In general overrides are not an issue for leaf packages but tend to be problematic for packages which get used as libraries.

After thinking about this I realize that the issue is not as big as I thought. a) when you develop on a project with cabal and install hnix and e.g. relude (with the different version) via your nix-shell cabal will still succeed in finding a working buildplin and b) even better, I think if you build a package with nix that takes relude and hnix as direct dependencies it will, I think, just build the package with the relude passed in via hnix and ignore the different relude passed in directly. It will only be a problem if you really try to combine two packages which have already been compiled with different relude or semialign versions.

Yes, the question of what deps expose in the env is important. But as we see, indeed - only direct dependencies get exposed & Nix would hide all others.
So far, I do not know about cases or can not imagine how packages (not even module level) compiled with different dependency versions & hard linked by Nix, how those can influence dependent packages that use other hard-linked library.

The main difference between library branches in Haskell is difference in API interface. But that is fully covered by the strong type system & the CPP preprocessor. So this case of compatibility fully is covered by Haskell.

If there can be real problems of misalignment between versions during compilations - then that issue is not raised only for Haskell, as then it touches Nix design & Nixpkgs practise as a whole.

Overall, I can imagine there could be some optimization limitations, if GHC for example V1Lib.func ... V2Lib.func, and because they implemented differently - it can not optimize them. But as I understand GHC would use/recieve dependencies code already in precompiled form and library functions used generally would not propagate through transitive package.

So for me it is hard to imagine the case when Haskell library dependency versions metter much. My knowledge of GHC is limited, and there can be some details & cases of such.

While when some out-of-band Nixpkgs package versions are removed - maintainer or itself checks what packages use/used it, or Nix language explicitly notifies maintainer to remove according overrides, which helps with in-time maintainence.

But I would consider patching as maybe a better practice and would look at the practice of its application. But patches can be left beyound their cause and intruduce side-effects, & in time people can loose the track of causes of what patch does and why it is there. Especially since patches are technology & language dependent processes. As it happens with myself in a couple of packages I maintain in Nixpkgs. As I see patches are still not handled structurally, no RFC or structural functions to add them, to help with their maintenance.

Thou, I still evaluating the approaches.

The core problem is propagation which is required for haskellPackages. If we override a package which is not just a leaf package to use a different version of a package from what we use in our “blessed” package set then it is possible that propagation causes two different version of the same package appear in the dependency tree of a package.

This is something cabal / GHC doesn't deal with well, so we try to avoid it. In fact the builder we use forbids it: