[mbakke]

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.

[patrec]

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.

[mbakke]

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