[Nix-dev] Re: Non-root packaging system + stdenvNative and replace-literal

[Dag Sverre Seljebotn]

2011/2/23 Ludovic Courtès <ludo at gnu.org>:
> Hi,
>
> [...]
>
>>>> I've been hacking around in that direction but need some assistance to
>>>> get going. First thing I tried was to play with patching
>>>> pkgs/stdenv/default.nix so that stdenv=stdenvNative or stdenvNix,
>>>
>>> Yes, that should work, assuming you mean changing this line:
>>>
>>>  if stdenvType == "i686-linux" then stdenvLinux else
>>>
>>> to
>>>
>>>  if stdenvType == "i686-linux" then stdenvNative else
>>>
>>> (or the same for x86_64-linux.)
>>
>> Yes, though I just took the more radical approach.
>
> I wonder if using ‘stdenvNative’ is a real win.
>
> In the short term, there’s an advantage: fewer packages are
> downloaded/built, resulting in lower disk usage.
>
> But in the longer term, if you keep using Nix over several months or
> years, then you get to fill your Nix store anyway and the space
> advantage becomes less and less important (because ‘stdenv’ is seldom
> upgraded, compared to, say, Python or the various apps/libraries you
> would use).
>
> More importantly, ‘stdenvNative’ is likely to yield to unreproducible
> builds given that important software components escape Nix.

Interesting point. Here's my reasons:

1) I think the most important point is psychologically. If I only
wanted to use this myself, then sure, I agree. But my problem is in
fact working with complex dependencies with my peers who are on
heterogenous systems and clusters. I want to push Nix as a way of
distributing (in particular my) scientific software. Telling people
that it'll be a one-hour build (or a hundred-megabyte download) before
they even get started, perhaps just to run my simple Python scripts,
is not a good way to create a low barrier of entry, and to get new
users.

"Perfect is the enemy of good." The important thing is to get away
from the current practice of everybody building their own software,
using institution-specific hacky shell-scripts and Makefiles that only
the PhD student that quit 3 years ago really understands.

As for reproducibility, I think it is important that one *can* use the
same package definitions to get a reproducible build. Say, one may
build a reproducible toolchain on the cluster nodes, which is where
the real computations that leads to publication of results will
happen. But, individual developers may not care that much, and use the
native toolchain on the laptop that they use for development and
debugging -- at least while everything works OK.

Again, I'm just making sure that something like stdenvNative is
possible before I decide to invest too much of my time in nix (and
don't, say, move back to sagemath.org). I just don't believe something
insisting on a seperate toolchain can gain adoption, it causes too
much (instinctual, irrational) dislike. To be clear, I may well use
stdenvLinux on my own laptop...

2) Regarding space, there's things like X libraries, GNOME, KDE and so
on, that one may want to have a dependency on in visualization
packages but which would really blow up the size (and yes,
stdenvNative doesn't help here, it was just a place to start.). I'm
sorry, but given the choice between linking with your X/GTK/Qt and
Ubuntu's, I'd take Ubuntu's. (And when I need a reproducible build, I
typically don't need a visualization GUI...I'd like to use nix for
both types of applications, but they have different needs).


Dag Sverre