[monday_]

How do Guix and Nix userbases and contributor resources compare?

I like Guix as a standalone package manager much much more. It has first-class support for single-file environment config, and it's in lisp! But a package manager system ultimately comes down to resources poured into maintaining and supporting packages, it's a bootstrap problem. It's clear that NixOS has substantial support. What about Guix?

[Filligree]

Nixpkgs is enormously larger.

I like Guix better in principle as well, but it should be clear that its principled stance on what software can be packaged means it's a nonstarter for many people.

[civodul]

Well, with more than 23K packages, it's fair to say that Guix can satisfy the needs of many people, too. A lot of programming languages are pretty well represented!

[rekado]

Not just 23K packages --- that's just what is in the main Guix channel. Nix has a whole bunch of packages that are created automatically, on the fly, such as most R packages. The Guix equivalent would be the humongous guix-cran channel, which provides automatically generated R packages.

So I think comparing the size of package collections is less interesting than checking whether your packages are included. Personally, I would have a very hard time with Nix because I need the quality control in Guix that gets me packages that have been built completely from source without depending on opaque upstream blobs (e.g. bundled jars, minified JavaScript, etc). Because of that I wouldn't be able to use Nix productively for bioinformatics, statistics, and things like pytorch in the same way as I use Guix.

[civodul]

Good point. It's telling that many Nix vs. Guix discussions focus on three topics: DSL, popularity, and non-free packages. Few people talk about package quality control even though it's rather crucial for day-to-day use.

A while back I wrote about what it means to package something like PyTorch with the kind of quality control Guix has: https://hpc.guix.info/blog/2021/09/whats-in-a-package/

[geokon]

I'm not at all living in the Guix world, so please forgive my ignorance here. (I actually kind of gave up on the dumpster fire that are native binaries and happily live in my JVM bubble these days) But based on your article, I think you can take things a bit further to their natural conclusion

The last step is dealing with CMake. You can actually produce correct/reproduceabile crossplatform, crossarchicture builds WITH diamond dependencies and all that jazz if you integrate with the Hunter dependency manager. I think it's the only way you can get to a point where you don't end up with redundant dependencies at different version numbers

I wrote this high-level article about it years ago: https://kxygk.github.io/hunterintro.html

I mean, I actually frankly don't see a clear line between CMake "build orchestration" tools and dependency managers like Guix. Ideally Guix would just take over the function of CMake entirely - but it's missing crucial pieces. I think fundamentally you have 90% of the pieces there. You've already specified the whole dependency tree and dealt with linking/paths. The last 10% is extracting what CMake calls the "toolchain file" - ie. the specification for how you what you build done (target OS, architecture, compiler, linker and compilation/linking flags).

Ultimately it feels like with a bit more abstraction GUIX could be a truly crossplatform build/package manager. One could imagine for instance passing it a -debug flag and having it propagate to all dependencies and build your whole world with symbols. Debugging would become "full stack". Or passing in another flag and building one huge static binary with all dependencies and then doing PGO on it. Building crossplatform would become a breeze. Introducing a new architecture would be simply a matter of specifying a new toolchain file

I spent way too much time on reproduceabile CMake builds. We had our library reprucibly building for a huge amount of targets from Windows to iPhone 9 with a dozen dependencies that had diamond dependencies and it all worked beautifully. But I was kind of horrified that almost nobody in the C/C++ world really care about this. The tools were there and no one was using them (granted Hunter, while easy to use, has a bit of learning curve)

Ultimately I think it's something that needs to be solved at a "higher level" of the package manager bc cross language monsters like PyTorch are the norm now a days

[pxc]

This. NixOS was very usable for me back when Nixpkgs was the same size as Guix's package collection is now.

Additionally, Guix's package collection growth currently looks exponential, year over year. The package collection size gap, assuming it sticks around at all, is only going to shrink (relative to the total size of either collection) and matter less and less over time.

[rekado]

Guix can be extended with channels, and so there are channels like nonguix (for nonfree software) or guix-science (for software that's too messy to include in Guix proper) that go beyond what quality control keeps out of Guix proper.

[throw10920]

> its principled stance on what software can be packaged means it's a nonstarter for many people

Including me. Guix actively makes it harder to install nonfree software, and that's against my personal principles, in addition to making my life harder on a practical level.

[rekado]

Guix actually makes an effort to make extensions of the maintained Guix channel as easy as the design choices allow. You can extend Guix in various ways: adding whatever channels you find or maintain yourself, extending it by setting GUIX_PACKAGE_PATH to a bunch of files, or by telling Guile to load some modules from somewhere else with "-L /where/your/files/are".

Guix doesn't care what software you install with it. It doesn't demand that you subscribe to any philosophy. The project just chooses to only package and distribute free software in the main channel. There are projects that have dedicated themselves to extending Guix with non-free or ... weird software. Guix will never go out of its way to make using those channels harder.

[Filligree]

But if you dare to use the non-free channel, you get shouted at if you try to ask for any form of assistance, even for problems entirely unrelated to it. Speaking from experience.

[rekado]

wat? I'm using channels providing nonfree software. Even "worse", I contribute to those channels.

These channels are not for #guix, because the discussion there is meant for the base channel provided and maintained by the Guix project; but on #nonguix, or #guix-hpc (for e.g. guix-science, guix-science-nonfree, etc) you get to discuss these channels all you want and get help.

[flurie]

Using nonfree packages in Nix feels like buying wine at the grocery store: small, infrequent, ephemeral hassles. Using nonfree packages in Guix feels like having to go to a small, obscure package store across town.

[mekeor]

I very much prefer the Guix community because based on my personal experience, it is more friendly and helpful than the Nix community. The main help ressources are the help-guix mailing-list and the IRC channel.