[Nix-dev] [Nix-commits] SVN commit: nix - r30988 - nix/branches/multiple-outputs-sandbox/tests

Shea Levy shea at shealevy.com
Tue Dec 20 18:38:05 CET 2011


Hi Eelco,

On 12/20/11 12:08 PM, Eelco Dolstra wrote:
> Author: eelco
> Date: Tue Dec 20 17:08:43 2011
> New Revision: 30988
> URL: https://nixos.org/websvn/nix/?rev=30988&sc=1
>
> Log:
> * Add a (currently failing) test that checks whether mutually
>    recursive outputs are properly rejected.

I know this is fighting a losing battle, but I thought I'd make one last 
argument in favor of allowing mutually recursive outputs.

In my view, the cost is minimal: add some logic to garbage 
collection/path deletion to detect multiple outputs and a db query for 
invalidating/deleting multiple paths at once. I think that extra code is 
only slightly more complex then the extra code required to check for and 
reject mutually recursive outputs. Once that code is added, I know of no 
additional costs to having recursive outputs allowed.

As for benefits, admittedly they are small since the outputs have to be 
built/downloaded together but I do think there is a potential benefit to 
being able to add one output to a user profile without bringing the 
other directly in, or to add one to buildInputs without the other, so 
that only some binaries are in $PATH or only some libraries can be found 
by stdenv's linker. Additionally, and I acknowledge that this is a very 
complex solution to a fairly insignificant problem, recursive outputs 
combined with hash rewriting allow us to solve the problem of 
mutually-recursive runtime dependencies (e.g. glibc depends on sh which 
depends on glibc) without any form of global state like /bin/sh while 
still allowing adding one dependency to your profile without the other 
(e.g. I could have bash in my profile without glibc).

In general, considering the cost is minimal and one-time (and I'm 
willing to write the needed code), I don't see a reason to disallow 
recursive outputs given that there are some potential benefits that may 
be leveraged in an as-yet unknown way by future nix users. I fully admit 
that these benefits are minor and may never be used, but what's the harm 
in allowing them?

Cheers,
Shea


More information about the nix-dev mailing list