Nixpkgs: pkgs.lib.inNixShell giving false positives

[domenkozar]

I was deploying a haskell app with nix-shell -p nixopsUnstable using following command:

[nix-shell:~/dev/nixops-deployments/avokado]$ nixops deploy -d avokado-production -I `pwd`

and clearly haskell default.nix wanted to build .env because I was in nix-shell. Not really sure how to approach this, but just making sure we have an issue for it.

cc @peti

[edolstra]

Workaround is to clear $IN_NIX_SHELL.

[peti]

I have no idea how to improve that situation from the Haskell/cabal2nix side, I'm afraid.

cabal2nix --shell generates those dual-use expressions that distinguish between builds and shell environments via pkgs.lib.inNixShell, and that mechanism is clearly flawed when trying to nix-build such an expression from inside of a nix-shell.

The only way to avoid that issue, IMHO, is to make sure that no --shell output is used for building outside of an interactive development environment, i.e. follow the 3-file-setup as described in the user manual at http://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download-by-type/doc/manual#how-to-create-nix-builds-for-your-own-private-haskell-packages.

[domenkozar]

Another would be for nixops and similar deployment apps to clear $IN_NIX_SHELL themselves

[ghost]

How about introduce another variable (eg: $EVAL_BY_NIX_SHELL)
and nix-shell should unset it after launched.

[domenkozar]

Closing as this is something that nixops should handle.

[nh2]

This hit me today too, nixops accidentally evaluating shellHook derivations instead of my actual contents. Is there a clean workaround by now?

[langston-barrett]

@Zimmi48 and I have been discussing exactly this problem. In summary: we would like to use lib.inNixShell to tell whether the current expression is being evaluated by nix-shell (as opposed to nix build), but right now it (as advertised) only tells us that we're the child process of a nix-shell.

One solution might be to have some sort of lib.calledBy, which specifies which nix tool is doing the calling.

[mpickering]

Are there any uses of inNixShell which take advantage of the current behaviour? I also ran into this problem today.