@chpatrick, thanks for your PR! By analyzing the history of the files in this pull request, we identified @peti, @cstrahan and @basvandijk to be potential reviewers.

This change is unnecessary. Just override mkDerivation with x : x if you want to have access to the original attribute set.

So your suggestion is to replicate

isHaskellPkg = x: (x ? pname) && (x ? version) && (x ? env);
  isSystemPkg = x: !isHaskellPkg x;

  allPkgconfigDepends = pkgconfigDepends ++ libraryPkgconfigDepends ++ executablePkgconfigDepends ++
                        optionals doCheck testPkgconfigDepends;

  propagatedBuildInputs = buildDepends ++ libraryHaskellDepends ++ executableHaskellDepends;
  otherBuildInputs = extraLibraries ++ librarySystemDepends ++ executableSystemDepends ++ setupHaskellDepends ++
                     buildTools ++ libraryToolDepends ++ executableToolDepends ++
                     optionals (allPkgconfigDepends != []) ([pkgconfig] ++ allPkgconfigDepends) ++
                     optionals doCheck (testDepends ++ testHaskellDepends ++ testSystemDepends ++ testToolDepends);
  allBuildInputs = propagatedBuildInputs ++ otherBuildInputs;

  haskellBuildInputs = stdenv.lib.filter isHaskellPkg allBuildInputs;
  systemBuildInputs = stdenv.lib.filter isSystemPkg allBuildInputs;

in our env script to find all the deps and always keep it up to date with generic-builder?

Replicating that seems excessive and error-prone.

Another approach would be to put envBuildInputs in passthru which has the advantage that it then also works for ghcjsi:

{ passthru = passthru // {
    envBuildInputs = [ ghcEnv systemBuildInputs ]
      ++ optional isGhcjs ghc."socket.io"; # for ghcjsi
  };
}

It would also be nice to have a function like envForPackages to go with this PR which can be used as:

pkgs.haskellPackages.envForPackages (hsPkgs: with hsPkgs; [scientific attoparsec])

which will then take all the envBuildInputs of the given packages and produce a single environment.

pkgs.haskellPackages.envForPackages (hsPkgs: with hsPkgs; [scientific attoparsec])

How exactly is that different from ghcWithPackages (hs: with hs; [scientific attoparsec])?

My understanding is that ghcWithPackages will recursively collect all dependencies of both packages and make them available to GHC. The know-know necessary for linking their dependent system libraries should be recorded in GHC's package database, so IMHO the generated environment should be equivalent to one that manually collects all dependencies and combines them into one build, no? What am I missing?

I guess what @chpatrick needs is to be able to create an environment in which all the dependencies of A and B are available except for A and B themselves. The problem with:

ghcWithPackages (hs: with hs; [A B])

is that it will also make A and B available. I guess this makes it problematic to work on these packages. @chpatrick is my understanding of your problem correct?

The idea behind:

envForPackages (hs: with hs; [A B])

is that it will make all the dependencies of A and B available except for A and B themselves.

Yes, that's correct. We have some packages that build incredibly slowly outside of cabal repl and we would like to set up an environment where we can cabal repl on them simultaneously, without having to wait 5 minutes for Nix to build them.

envForPackages (hs: with hs; [A B])

Okay, I think I got it. I believe this function is going to be fairly simple to provide. I'll suggest a solution in a bit.

This issue is addressed by #36393.