[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