cc @domenkozar

cc @srhb does this address the issue? :)

Thanks @vaibhavsagar !

Hi, thanks @vaibhavsagar !

This improves one aspect of the situation, but not all of it.

The problem is that if a user has an overlay that uses extend, override doesn't even exist, and this will cause a bunch of nix tooling to misbehave because the cachix expression then fails to evaluate completely.

Arguably, this is not the fault of cachix at all, but the fact that extend is fundamentally broken, but it's still a really bad user experience. This is why I argued in the linked issue that in-tree packages maybe shouldn't use either of haskellPackages.override and haskellPackages.extend but this definitely seems to be something we should discuss and come to a kind of consensus on.

I see two options:
(a) Disallow the use of haskellPackages.{override,extend} in-tree because we might break user setups due to this.
(b) Allow the use of haskellPackages.override (never extend), and accept that this makes it impossible for users to use extend. Since extend is broken anyway, it's OK that users have to deal with rewriting their own overlays or changes.

If we converge on (a), this PR does not suffice. The expression will have to be rewritten to use neither of the haskellPackages mechanisms.

If we converge on (b), this PR suffices.

Thoughts?

cc @basvandijk @peti

What happens if we simply use .extend internally instead? As far as I know, it'll always be there, and as long as we don't expose the changed haskellPackages to the users, there's no nasty surprise. Does that make sense, or did I forget something here?

extend picks up the overrides as well. sgtm

Updated!

I've pushed 4c6be1f as those overrides are not needed anymore. I'll make sure I use extend next time. Thank you!