One aspect of Guix I found to be really fascinating: That there is basically no conceptual difference between defining a package as a private build script, and using a package as part of the system.
Let me explain: Say you wrote a little program in Python which uses a C library (or a Rust library with C ABI) which is in the distribution. Then, in Guix you would put that librarie’s name and needed version into a manifest.scm file which lists your dependency, and makes it available if you run guix shell in that folder. It does not matter whether you run the full Guix System, or just use Guix as s package manager.
Now, if you want to install your little python program as part of your system, you’ll write an install script or package definition, which is nothing else than a litle piece of Scheme code which contains the name of your program, your dependency, and the information needed to call python’s build tool.
The point I am making is now that the only thing which is different between your local package and a distributed package in Guix is that distributed packages are package definitions hosted in public git repos, called ‘channels’. So, if you put your package’s source into a github or codeberg repo, and the package definition into another repo, you now have published a package which is a part of Guix (in your own channel). Anybody who wants to install and run your package just needs your channel’s URL and the packages name. It is a fully decentral system.
In short, in Guix you have built-in something like Arch’s AUR, just in a much more elegant and clean manner - and in a fully decentralized way.
I’d argue that using Scheme as a configuration language is not such a steep barrier. Any Emacs user has surely done a little bit of configuration setup by pasting bits of configuration statements into a file called
.emacs. Well, the configuration language he or she was using is actually Emacs Lisp. There is no border between configuring Emacs by text file, and writing code in Lisp.The biggest problem with Scheme as config language is that it is sloooooowwwww. Nix is already quite sluggish when it comes to configuration changes, in Guix it’s a lot worse, and it’s unlikely to change anytime soon, given that Scheme allows macros and other hacks that might make it difficult to properly cache or index the package database.
It depends on the implementation, but Schemes and Lisps are in general not that slow - some use JIT compilation to native code - and Guile is not a slow Scheme.
One aspect of Guix I found to be really fascinating: That there is basically no conceptual difference between defining a package as a private build script, and using a package as part of the system.
This is true for Nix as well.
The two main advantages of Guix are the language (which is well-known and comes with lots of good tooling and other support) and the package bootstrapping.
I had a go at using guix as a package manager on top of an existing distro (first an immutable fedora, which went terribly, then OpenSUSE). Gave up for a few reasons:
- As mentioned in the article,
guix pullis sloow. - Packages were very out of date, even Emacs. If I understand correctly, 30.1 was only added last month, despite having been available since February. I get that this isn’t the longest wait, but for the piece of software you can expect most guix users to be running, it doesn’t bode well.
- The project I was interested in trying out (Gypsum) had a completely broken manifest. Seems like it worked on the dev’s machine though, which made me concerned about how well guix profiles actually isolate Dev environments. This was probably an error on the dev’s part, but I’d argue such errors should be hard to make by design.
All in all I love the idea of guix, but I think it needs a bigger community behind it. Of course I’m part of the problem by walking away, but 🤷
- As mentioned in the article,
guix pullis sloow.
This one has beem discussed on several forums discussing the original blog post, like here or also here on lobste.rs
Part of the reason for slow pulls is that the GNU projects savannah server, which Guix was using so far, is not fast, especially with git repos. Luckily, this is already being improved because Guix is moving to codeberg.org, a FOSS nonprofit org which is hosted in Europe. So if one changes the configured server URL, it is faster. (On top of that interested people might use the opportunity to directly take influence, and donate to codeberg so that they can afford even better hardware 😉).
- As mentioned in the article,
- As mentioned in the article,
Why Guix packages are unsuitable for graphical desktop apps ?
They aren’t?
