[Nix-dev] is there something like unsafeImpureEnvVars?

Ben Franksen ben.franksen at online.de
Sun Apr 13 23:03:12 CEST 2014


Hello

Is there *any* way (besides hacking the Nix source code) to circumvent the 
limitation on impureEnvVars, i.e. that one has to provide the hash up front, 
making the derivation fixed-output? What I am asking for is something akin 
to unsafePerformIO in Haskell (which exists for similar situations, and 
motivated the name unsafeImpureEnvVars in the subject).

Effectively I want to be able to say to Nix: "I swear these variables are 
used in a pure way, just believe me."

Background:

I want to use fetchdarcs for remote repositories via ssh; we use darcs to 
version control our software internally (even stuff we get from the outside, 
to track patches for customisation and bug fixes). We use tags to identify 
versions and have lots of darcs repos, all on a single server, accessible to 
developers via ssh.

Unfortunately, fetchdarcs fails in this case because, to avoid being asked 
for a passphrase, ssh (in this case called via darcs) needs to know how to 
access a runnig ssh agent, and this knowledge is encoded in two environment 
variables: SSH_AGENT_PID and SSH_AUTH_SOCK. But of course these are not 
defined in the builder, its environment gets cleared before it starts.

Now, there is the attribute impureEnvVars. But that works only if you pass 
the expected hash to the builder (so the derivation becomes fixed-output). 
That means either I hard-code the expected hash into the derivation, or pass 
it as an argument. In both cases, I need to find out the hash before-hand. 
This makes it very inconvenient for users to add new version of packages.

Note that this is *only* because of the two environment variables. I can use 
fetchdarcs just fine with any local path or remote http url without 
providing any hash.

Note also that use of these variables does not imply any impurity, they are 
only used for authentication.

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." -- Scott Adams



More information about the nix-dev mailing list