@peti one of the goals of 74f5fe5 was to allow passing in a custom stdenv, which would be used for genericBuilder's mkDerivation call. That does work, but if packages take stdenv as an parameter for any reason, they'll get the default one instead. This change remedies it.

I use custom stdenvs to fix the sierra issue without rebuilding GHC to hard-code a different C toolchain.

@Ericson2314, I am sorry, but I still don't understand. Where exactly would you like to override stdenv and why is that not possible today?

Are you aware that hackage-packages.nix binds stdenv as an argument? Haskell packages in Nixpkgs never need stdenv as an argument -- it's always in scope. No lookup in self takes place.

@peti

Where exactly would you like to override stdenv

Since 74f5fe5,

callPackage makePackageSet { stdenv = ...; }

Are you aware that hackage-packages.nix binds stdenv as an argument?

What about stand-alone cabal2nix? stdenv would be unbound unless it is a set-pattern parameter.

Yes, expressions generated by cabal2nix need a stdenv argument, but the only place they ever use it is to access stdenv.lib.licenses. Arguably, we could change that code of take lib as an argument rather than stdenv, but in any case it should make no difference for your use case, no?

@peti What I've done is master...obsidiansystems:more-sierra-hack#diff-209cb9d64e0f91ce90d31759e43bba01R48 That could be rewritten, but I'd think that if callPackage provides self, which it will because of the pkgs in mkScope's definition, it might as well provide the right one.

@peti Also consider

1. People do still write Haskell packages by hand

2. We could perhaps get rid of those 3 outer arguments in haskell-packages.nix, making there more obviously be one source of truth.

@peti Thanks!