This has come up before. Personally, I don't want system libraries to be found automatically. I want the necessary search paths to be configured with Cabal so that these paths are recorded in the generated package config files. This is necessary for packages compiled inside of a nix-shell environment to work outside of that environment, too.

See also #28033 for previous discussions.

Do you think your concerns in #28033 are still relevant now that both cabal and stack read shell.nix?

In any case, systemBuildInputs should not be in nativeBuildInputs because these inputs are for the host machine, not the build machine. So if you don't want systemBuildInputs to go into buildInputs, then they should be removed entirely.

now that both cabal and stack read shell.nix?

Didn’t know about that, sounds like a horrible solution. Suddenly every build tool knows about every other build tool 😟.

This has come up before. Personally, I don't want system libraries to be found automatically. I want the necessary search paths to be configured with Cabal so that these paths are recorded in the generated package config files.

Since there’s now multiple people who independently requested picking up the shell environment, maybe it’s time to find a compromise that works for both use cases?

Didn’t know about that, sounds like a horrible solution. Suddenly every build tool knows about every other build tool 😟.

I think we've been back and forth about this before. I see what you're saying, but let me counter: Nix is set up like a build server; cabal is just using it like one!

It's better than this situation:

the necessary search paths to be configured with Cabal so that these paths are recorded in the generated package config files

This only works because of a bug in cabal that the package config cache is not invalidated when the environment changes. And when the cache is finally invalidated, it breaks the cache regeneration. Finally, when cabal projects are enabled by default, it probably won't work at all because the cache invalidation bug will be fixed.

Since there’s now multiple people who independently requested picking up the shell environment, maybe it’s time to find a compromise that works for both use cases?

Overlays?

In any case, systemBuildInputs should not be in nativeBuildInputs because these inputs are for the host machine, not the build machine. So if you don't want systemBuildInputs to go into buildInputs, then they should be removed entirely.

You are right, that is a good point. Let's fix that issue now and worry about whether to remove them entirely or not in a separate PR.

I'll fix this. The solution is a wrapped cabal install and a setup hook such that.

1. NIX_CFLAGS doesn't get the -isystems and -Ls
2. NIX_CABAL_FOREIGN gets the --extra-*-dirs instead

Then we properly specify all the deps exactly the same way in generic build and shell environments. In fact, we can use the setup hook with generic builder too.

If anyone can review #33358 in the meantime, that would be nice. It will be easier to get the dependency types correct with that in place.

WIP #33368