mkShell alternative that doesn't include stdenv, for use with direnv or impure nix develop

[lilyball]

Problem you want to solve

I want to use direnv (using nix print-dev-env) or nix develop (or nix-shell even) to give me an environment with a set of packages but I don't want to pull in anything from stdenv (unless I requested it). As it is, using mkShellNoCC on my system includes bashInteractive, coreutils, findutils, diffutils, gnused, gnugrep, gawk, gnutar, gzip, bzip2, gnumake, bash, patch, and xz, all in addition to the packages I requested.

Using a shell to reproduce the build environment of an existing package should include all this, but when I'm using mkShell it's because I want to add specific dependencies to my existing environment. A pure shell probably needs stdenv, but it just gets in the way with my impure shell.

The fundamental problem here is that mkShell/mkShellNoCC depends on stdenv, and so tools like nix print-dev-env pull in all of the stdenv packages too.

Proposed solution

Add a new library function that acts like mkShell except it produces a derivation that itself does not depend on stdenv. nix develop should only add the packages that are listed explicitly.

If possible, it should consider doing this only for "impure" shells, and still pull in stdenv for "pure" shells.

[veprbl]

You still want to run the setup hooks though? Those do rely on stdenv.

[lilyball]

I'm not certain which packages rely on them and which don't. I'm not pulling in compilers. I am doing things like autoconf, jq, etc. One project does use pkg-config and openssl, which really just needs a particular env var set, and I'm not sure if that's constructed with a setup hook or some other mechanism.

I suppose what I really care about here is just ensuring the PATH var in my shell contains only what I requested. In theory that means "save PATH before doing anything, run setup, then reset PATH and rebuild it using just the declared dependencies without stdenv". This approach also provides a convenient spot to say "don't do this last part if it's a pure shell".

[veprbl]

If you can work without the shell hooks, there is already nix shell:

# env -i $(which nix) shell nixpkgs#hello -c /usr/bin/env | grep PATH
PATH=/nix/store/lj6qjfzhk25ynvyk7d6i6a2v5k9aa5gp-hello-2.10/bin

Otherwise, unsetting of unwanted paths can be done in the shellHook.

[lilyball]

Using nix shell to provide a whole set of dependencies at once seems rather awkward. And of course if I need anything else like PKG_CONFIG_PATH then this doesn't work (presumably this var is populated via a shell hook).

I actually do have a cleanStdenv wrapper I wrote that basically uses a preHook to record the initial PATH provided by stdenv, then a shellHook that removes this from the new resulting PATH, but it feels a bit fragile and I'm unsure whether it will work if I explicitly request any of the stdenv packages. I'm also unsure if there's anything else from stdenv that I accidentally inherit from this (I haven't done a detailed inspection of all resulting env vars yet).

Having something in nixpkgs that did this officially would feel a lot more reliable. And this also feels like something that should be generally useful for others.

[legendofmiracles]

#132617 this PR adds a shell that only relies on bash.

[lilyball]

Interesting. That looks like it does something very similar to what I want. It does mean I can't trivially pull in openssl + pkg-config without managing PKG_CONFIG_PATH myself unfortunately, and I'd prefer to not even have bash in my path, but it still does most of what I want.

The openssl + pkg-config thing though is something that would be very helpful to be able to solve properly. I don't know if that's "do another mkShell variant that runs setup like normal and then fixes up PATH to omit stdenv packages" like what my local cleanStdenv wrapper attempts, or maybe something like a wrapper that runs a mkShell variant that records all the resulting env vars, and then pulls in the non-PATH vars into the shell and reconstructs PATH based on the selected packages. There's no immediately obvious answer here.