Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkgs.lib.inNixShell giving false positives #9438

Closed
domenkozar opened this issue Aug 25, 2015 · 8 comments
Closed

pkgs.lib.inNixShell giving false positives #9438

domenkozar opened this issue Aug 25, 2015 · 8 comments

Comments

@domenkozar
Copy link
Member

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
Copy link
Member

Workaround is to clear $IN_NIX_SHELL.

@peti
Copy link
Member

peti commented Aug 25, 2015

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
Copy link
Member Author

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

@ghost
Copy link

ghost commented Aug 27, 2015

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

@domenkozar
Copy link
Member Author

Closing as this is something that nixops should handle.

@nh2
Copy link
Contributor

nh2 commented Jun 20, 2017

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

@langston-barrett
Copy link
Contributor

@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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants