Had a VM GUIX "system" (really I think its more of package manager
overlay) for a while (18 months ago) but encountered some
problems. The main feature AFAICS is that it maintains the state of
the system and packages all very cleanly via it's own nix build system
which is like a snapshot of everything.
The sell is that it's very recoverable - in theory you can rebuild
from a single file. That's very appealing for VMs that need to be
moved about.
Unfortunately I needed a couple of things that were available only
through apt. Now, Guix said it was perfectly happy to mix package
management, (a bit like mixing pkg and ports in BSD) - but don't do
that. It all went horribly wrong with confusion over which binaries
were running at any time and when I did try to port it, it broke.
I like lispy things so will give Guix another try one day, but it
needs you to fully embrace its philosophy and no half measures.
I'd like to point out that Guix is closer to ~52,000 packages than the ~29,000, as we maintain a bunch of things in separate channels that nixpkgs includes in its monorepo (e.g. the 20+k CRAN packages). See https://hpc.guix.info/channels and https://hpc.guix.info/channels/non-free for some popular channels used by HPC folks.
Huh. I think that info should be more prominently displayed.
Just a few minutes ago, I decided to put off trying guix until later because it had fewer packages than nix, and was missing several that I need, that nix has.
I love that this goes both ways. What other pair of Linux distros mutually offer first class support for using each other's package managers alongside their own??
It's a cute little testament to the fundamental strengths of the functional package management paradigm, as well as helping users on either side of the fence fill some gaps in a pinch and providing more/easier opportunities to compare notes and inspire improvements.
Nix is conceptually extremely similar to Guix, but a different implementation! It uses its own programming language, also called Nix, and has a less strict stance on free software.
Guix uses Nix under the hood (learned this when trying to compile it). Perhaps learning Nix first will let the grandparent be more effective in Guix later.
Guix includes a copy of the nix-daemon. It's a relatively small C++ program that manages the store. We reuse it because there was no point in writing a replacement for something as low-level as the daemon. Guix compiles its package definitions down to the same kind of file format that the old Nix daemon understands.
(It's a bit funny to me that GNU has a reputation for NIH-ing projects, but when a GNU project doesn't reinvent the spokes on a wheel it also attracts various forms of criticism.)
> The daemon also is a key part of the history of Guix. The Guix project started mixing Guile with ideas from the Nix project, and the guix-daemon is a fork of the nix-daemon with some tweaks made over the years. Rather than being implemented in Guile though, the daemon is implemented in C++ with some helpers written in Guile.[1]
The Summer of Code project was unsuccessful for personal reasons. The project was also never even close to high priority, because the daemon just isn't all that interesting beyond performing its one job of implementing the functional package management paradigm. That is to say, for a long time there was very little to be gained from a rewrite.
The most recent project has only just started and is spearheaded by Chris Baines, who has extensive experience with the build side due to his work on a (Guile-based) build coordinator used by one of the two major independent build farms.
I don't think the older branches contain much that needs to be ported; most of the work from past projects has in fact made it into Guix already and is used for other features --- just not in the daemon. If the Guile daemon project is successful, the daemon will incorporate many of these existing features for build isolation and coordination.
Guix forked and modified only the Nix build daemon which isn't user visible. Learning the Nix tools and language will not teach you very much about how to use Guix.
There is no mixing ports and pkgs in FreeBSD (I assume you mean that one). When you build a port, it builds a package and installs that. You run into big rebuilds/reinstalls when versions mismatch between your ports tree and pkgs repo.
Guix/nix can't be mixed with existing package managers, but can exist on the same machine. You're (most likely) going to have duplicates and different versions of the same thing.
Yes my previous is mainly with FreeBSD. Your response highlights my
mistake. As a Guix noob (but with decades of apt/yum/rpm/pkg kinda
experience) I misunderstood how these things interact, and failing to
manage Guix was most definitely my fault.
Don't get me wrong, I love Guix and the philosophy, but my heart cries
out for some Grand Unified Manager of Packages (GUMP), something that
can track whether things need building from source, or can be brought
in as binary from an apt or rpm, or build those packages as
intermediate stages. I kinda thought that's what Guix was going to
do. Now I see that a unified package manager is probably unreasonable
and that we are headed more toward containerised "Snap/flatpck" way of
things - which I don't like.
> something that can track whether things need building from source, or can be brought in as binary from an apt or rpm, or build those packages as intermediate stages. I kinda thought that's what Guix was going to do.
I mean, that sortof what nix (and I assume guix) is though, right? As long as your ok with the binary cache for a replacement for apt/rpm (with the caveat that sometimes pkgs can be built on .deb or .rpm)
The sell is that it's very recoverable - in theory you can rebuild from a single file. That's very appealing for VMs that need to be moved about.
Unfortunately I needed a couple of things that were available only through apt. Now, Guix said it was perfectly happy to mix package management, (a bit like mixing pkg and ports in BSD) - but don't do that. It all went horribly wrong with confusion over which binaries were running at any time and when I did try to port it, it broke.
I like lispy things so will give Guix another try one day, but it needs you to fully embrace its philosophy and no half measures.