2011/2/23 Ludovic Courtès <[email protected]>: > 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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
