Hacker News new | ask | show | jobs
by patrec 2052 days ago
Thanks for taking the time to write a up a detailed and informative answer!

I agree wrt desirability of grafts as an escape hatch (I think there's been some undocumented crappy version of this in nix for ages, no idea what keeps it in limbo). I also agree that bootstrapping is better in principle.

The search path (in nix?) thing, I don't fully get -- can you expand what you mean? Concerning not needing to patch upstream -- the world is full of setup.py scripts and other cruft that tries to download random stuff from the internet or write and read hardcoded system paths -- how do you deal with that?

> It's funny that you mention "non-machine editable Scheme code". In the Lisp world, code is data

One of the ego-salving lies lispers like to tell themselves ;) If it were so they'd enjoy world class refactoring, whereas in reality they can't even auto-indent code without manually futzing around with symbol properties in emacs. I haven't fully traced how guix update works, but looking at edit-expression it doesn't look very code-is-data to me (the replacement function operates at character not ast/sexp level; read is only called for side-effect as a hack twice).

1 comments

With regards to needing patches, the comments in this thread suggested many packages needed patching to work on NixOS at run-time, but I have probably misunderstood.

At build time obviously Guix has all the same problems with packages that attempts network access (to download test data or whatever). I found it easier/more intuitive to provide such additional resources with Guix, but then it's been four years since I used Nix!

On the topic of search paths, IIRC Nix uses a combination of wrappers and "setup hooks" to configure things like C_INCLUDE_PATH or PYTHONPATH. In Guix, such search paths are "first class" and gets automatically configured when the relevant packages are installed to a profile.

That means no hook or wrapper is necessary, and it works with arbitrary profiles as well as "guix pack", etc -- and it is also possible to compose profiles (an emerging pattern among Guix users is to have different profiles for different uses -- a step towards privilege separation).

You'll find almost no hard coded references to "~/.guix-profile" or "/run/current-system" in Guix.

Wrt the updater code, apparently you have studied it more than I have! I think my point still stands though -- that approach would not work if not for the fact that sexps are well-structured.

Ah, OK, you mean stuff like this, right? https://github.com/NixOS/nixpkgs/pull/85103

I haven't often run into wrapper issues, but when you do it's a pain. So thanks for the pointer, I should probably look at how guix does it.

Indeed that approach looks very similar.

In Guix search paths are properties of the packages that consume them: for the GStreamer example in that PR all the plugins provide the search path attribute, whereas in Guix it is only set once, on the 'gstreamer' package.

The Guix approach has a limitation though, in that users must manually install gstreamer for the plugins to become visible in the profile. It's one of the oldest high-severity bugs in Guix: https://issues.guix.gnu.org/22138