Nix and guix are ahead of their time

As a gentoo linux user who maintains a package repository, I can keep up with the requirement to learn gnu guile and write guix packages and guix services.

However, many language build systems don’t natively support multiple library paths. The end result is that guix packages add their own multiple path patches to upstream softwares because they can’t wait for upstream softwares to support multiple paths.

Patching various upstream softwares written in various programming languages is way beyond one man’s capacity to do free work or even paid work.

For all relevant upstream softwares to support multiple paths, we would have to wait a long time until nixos becomes so popular that softwares support multiple paths by default.

For now, I’m not moving to gnu guix because build systems I depend on everyday don’t support multiple paths. I don’t know how to patch them. I don’t have time to learn them all, and I don’t have money to pay developers for patches.

Deviating from file hierarchy standard is a unique idea, but purely functional package managers have yet to wait for their time.

Nix/Guix are essentially the Mod Organizer of GNU/Linux distributions.

For those here who aren’t Skyrim modding enthusiasts, ModOrganizer was a tool that came around a few years after the game was initially released. Bethesda games have always had amazing moddability, so there were a number of tools that were used for installing, organizing, and managing various mods. Several of these (such as Nexus Mod Manager) were fairly entrenched.

They all worked similarly, pick the mod and have the manager throw the files into your Skyrim directory while adjusting any configuration files needed. It worked, but generally unless you had some experience you were probably going to have to occasionally wipe your Skyrim directory and start from scratch because you messed something up.

Then along came Mod Organizer (and eventually Mod Organizer 2, but that’s a separate story). Mod Organizer was ahead of its time. Instead of just dumping everything into the Skyrim directory, it instead built a virtual filesystem that first loaded the Skyrim files, then linked in all the mods as well, using the configuration that you designed. Then, when ready, it would launch the game from this virtual environment.

Mods could now be swapped/reordered/changed as needed, and it was now possible to set up numerous profiles that used any number of different mod configurations, and best of all, it did all of this while leaving your base Skyrim directory untouched and pristine.

Eventually additional tools like Wabbajack were added that utilized Mod Organizer to its full extent, granting the ability to do one-click installs of massive mod configurations that completely transformed the game experience. It took awhile, but eventually Mod Organizer became the default/go-to tool for Skyrim modding.

I find Guix/Nix eerily similar to Mod Organizer in terms of its value proposition. I also hope that it sees a similar timeline, where once everyone sees the benefit they eventually adopt it as the new standard.

I’m not yet sure if Guix Home is the system’s Wabbajack, but I’ve been using Guix as my main workstation for about a month now and really love the system. There are still plenty of warts, but I love the potential that the system has.

1 Like

What warts are there in guix?

After pondering for a while, a long list of search paths seems to be slow and inefficient.

A symlink farm seems more efficient than a long list of search paths.

For transitive dependencies, transitive symlinks look natural. However, if guix copies symlinks from transitive dependencies, then we end up with direct symlinks instead of transitive symlinks. Direct symlinks are even more efficient than transitive symlinks. Since guix is just guile code, code can be written to write direct symlinks to transitive dependencies.

Direct symlink farm seems to be the way. Is there a reason that search paths are preferred to symlink farm?

One anticipated disadvantage of direct symlink farm is disk usage.

Yes, tools like that have a long history in PC gaming, predating Skyrim and its predecessors. :slight_smile: Some were quite elaborate, e.g. F4Patch for Falcon 4.0, which entailed applying various patches to game files in non-conflicting ways. As you said, they enabled combining various mods and switching between them. The key is reproducibility, to declare what result you want and ensure that that result is what is produced.

These kinds of detailed questions would best be asked on Guix mailing lists, where the Guix developers are (or, even better, spend some time reading historical discussions, since Guix is not a new project, and these decisions were made over years and probably lengthy discussions).

Another gotcha is guix shell.

For guix shell to be useful, there should be enough packages in the first place.

Now, your scripts need to run on guix shell.

#!/usr/bin/env -S guix shell emacs emacs-htmlize -- emacs -x

This script is not portable to other distros. NixOS has nix shell. If you want something portable, your only option is to turn your script into a package.