Nix Flakes and their Guix Equivalents
34 points by Kratacoa
34 points by Kratacoa
after reading the post, I’m still not sure how do I specify and pin dependencies for a project (so I can publish it and share with others) without manually finding and specifying the commit hash for each (transitive) dependency in channels.scm. the time-machine thing seems to only work for guix package set, not for other out-of-tree dependencies?
The guix time-machine command is genuinely unique and has no direct flake equivalent. It lets you travel to any point in Guix's history — not just to pinned dependency versions, but to a completely different state of the package collection
you can quite easily run code from another point in nixpkgs history:
nix run github:nixos/nixpkgs/<commit hash>#<package>
guix is unique here in that it doesn’t separate version of the package collection from the version of the package manager: running an old package involves also running an old release of guix. I’m honestly not sure why would I want that.
Flakes can pin dependencies, but you can't easily say "run this with the version of nixpkgs from six months ago" without manually finding and specifying the commit. With Guix,
guix time-machine --commit=... --does exactly this.
I really don’t understand this statement. posts says that flakes require “manually finding and specifying the commit” and then provides a guix command that requires to specify the commit. you can also override the version of nixpkgs for some flake by using --override-input, although it is messy and one of the things I’m trying to improve with unflake.
Before (or if they don't) they chime in, I'll try to address a few things. I'm less experienced with Guix usage than the author of the post, but I'm likely acquainted enough with the docs to give pointers.
after reading the post, I’m still not sure how do I specify and pin dependencies for a project (so I can publish it and share with others) without manually finding and specifying the commit hash for each (transitive) dependency in channels.scm.
The workflow is that you develop in some dedicated guix shell environment, and use guix describe to specify (guix describe -f channels > channels.scm) all the commit hashes into a channels.scm once you get to a stage where you want to share it.
From the docs on declaring channel dependencies, it seems that can specify the commit of your dependency, but if they in turn also have dependencies, it doesn't look like there is an option to verify whether you can expect them to have their dependencies pinned to a certain commit at any time.
the time-machine thing seems to only work for guix package set, not for other out-of-tree dependencies?
The --commit= notation yes, however you can additionally load channels with -C from some file.
guix is unique here in that it doesn’t separate version of the package collection from the version of the package manager: running an old package involves also running an old release of guix. I’m honestly not sure why would I want that.
It allows breaking changes to the package manager and package records without losing out on history/reproducibility.
thanks for your answers!
it doesn't look like there is an option to verify whether you can expect them to have their dependencies pinned to a certain commit at any time
I think I don’t actually want them to have their dependencies pinned (like in flakes), but rather I want to have a top-level lockfile that specifies a hash for every transitive dependency, and I don’t really want to write it manually. that’s what e.g. ~every language package manager does.
The --commit= notation yes, however you can additionally load channels with -C from some file.
but then I lose the “time machine” aspect, right? since I can’t specify the specific commit for a custom channel.
I think I don’t actually want them to have their dependencies pinned (like in flakes), but rather I want to have a top-level lockfile that specifies a hash for every transitive dependency, and I don’t really want to write it manually. that’s what e.g. ~every language package manager does.
I'm not sure what you mean by "hash for every transitive dependency". I'll try to guess:
It is mandatory for Guix package definitions to ask you to specify hashes for all the files required for some package (see defining packages)
but then I lose the “time machine” aspect, right? since I can’t specify the specific commit for a custom channel.
-C loads a channels.scm which is the same format that is referred elsewhere in the article, hence it should have the same features.
I'm not sure what you mean by "hash for every transitive dependency".
let’s say my project depends on channel A, and channel A in turn depends on channel B. I want my root lockfile to contain hashes for both A in B, similarly how it would be with cargo or npm.
-C loads a channels.scm
yeah, so I need to provide a channels.scm file? I can’t ask “give me channel from this repo at this commit”? I can either travel to a specific commit of the main package set, or I need to manually fetch the required version of a custom channel.
Yes you can, you can have a channels.scm tracking branches or specific commits and following the instructions Kratacoa gave you earlier (guix describe ...) you can generate a channels-lock.scm pinning specific commits
let’s say my project depends on channel A, and channel A in turn depends on channel B. I want my root lockfile to contain hashes for both A in B, similarly how it would be with cargo or npm.
Oh, sorry for the misleading answer. Anyway.
Do the docs on channel authentication and channel authorization answer your doubts?
yeah, so I need to provide a channels.scm file? I can’t ask “give me channel from this repo at this commit”? I can either travel to a specific commit of the main package set, or I need to manually fetch the required version of a custom channel.
If you need to pin specific desired commits that are otherwise not specific in the repo's channels.scm, afaict yeah you need to write it manually in the file to load.
I forgot to mention that the file can be loaded either locally or from an uri.
You can check the docs on invoking guix time-machine here.
I feel like I’m not explaining myself well. channel authentication explains how to manually specify a hash. I want for a dependency resolver to find out what the current latest commit is for every required dependency, including transitive ones, and write all their hashes into a lockfile. I do not think that is currently possible with Guix, as far as I am aware, because in Guix you’re supposed to manually specify the hashes for your direct dependencies only, and the full dependency tree is not stored anywhere in the lockfile.
I forgot to mention that the file can be loaded either locally or from an uri
this is interesting and answers that question, thanks! with this I think guix time-machine is roughly equivalent to nix shell, modulo using an older version of nix itself for evaluation.
I feel like I’m not explaining myself well
Rather it's my fault for trying unskillfully to guess what you're fishing for!
Channel authentication explains how to manually specify a hash. I want for a dependency resolver to find out what the current latest commit is for every required dependency, including transitive ones, and write all their hashes into a lockfile.
Ok, I think I got it.
Guix channels are Git repositories, and for them to be used by Guix they need to be added to the store; this is done by both guix pull and guix time-machine.
When you do that, you create a guix profile, which carries along with it information used to build it, such as the channels used. Hence, you also have the commit IDs used for that profile (otherwise it wouldn't be reproducible), and those are what guix describe shows: the ones in use by your current profile.
If you want a general log of the profiles built from pulling channels, you have guix pull --list-generations.
That said, I think Git commits are the hashes you're looking for. Is that correct?
P.S. I skipped a few things hoping it's understandable from Nixland, to shorten.
this is interesting and answers that question, thanks! with this I think guix time-machine is roughly equivalent to nix shell, modulo using an older version of nix itself for evaluation.
For me as a Guix user, it's an augmented guix shell :)
One other nitpick: time-machine can also go forward relative to your system. Not that I know what to use that for haha
maybe profiles is what I need? my usecase is distributing a program with its dependencies, where some dependencies might come from third-party channels. I want something I can commit into my repo such that anyone can use it. the OP described that you can have channels depending on other channels, but this does not provide a way for a channel to lock its transitive dependencies.
as an imperfect example: here’s a flake repo, packaging a program I wrote. its lockfile locks an indirect dependency to a specific commit, so when someone nix runs this repo, they will get the exact version of every dependency required, including indirect ones. if I can commit a profile into a repo and share it with another person, then it might be what I need.
One other nitpick: time-machine can also go forward relative to your system. Not that I know what to use that for haha
that’s actually quite interesting, because that implies you can build a package that uses some feature that is not implemented in your “system” guix
Update on the previous message:
there are some approaches on Codeberg: https://codeberg.org/guix/guix/issues/431
after reading the post, I’m still not sure how do I specify and pin dependencies for a project (so I can publish it and share with others) without manually finding and specifying the commit hash for each
this is possible by building a reverse index of nixpkgs for this purpose: commits X -> Y of nixpkgs contains version A of given package. this is very expensive to do given that it needs a checkout of nixpkgs at each commit. maintaining the index after the first build should be cheap.
They’re asking for Guix, and not for that type of reverse mapping afaict (not package version -> package set commit, moreso about the transitive dependencies not being automatically locked).
This website is incredibly frustrating to read on mobile: the text is (slightly) too small, and it keeps fighting my scrolling.
I haven't been able to read past the first comparison because it keeps slingshotting me back to the Table of Contents.
I literally cannot read it at all. It's like a yo-yo. Top ten most frustrating experiences ever, and one of the top 10 articles I've wanted to read in recent memory. So, so, frustrating and disappointing.
it happens on desktop too. ridiculous and purposefully inaccessible.
What is your browser? I don't have this problem on Firefox.
Coopi says
the issue should only be happening on narrow screens, like on mobiles and browser windows tiled narrowly, so that might explain how u didnt face it. (i fixed it now tho)
It does happen on Zen and Firefox dev
Oh, I think I misunderstood you. Did you mean that the table of contents scrolls back, not the whole page?
If yes, then I also have it.
So I have notified coopi about the issues with the site and this thread, lets hope they fixes the issues soon.
And as for the comparison, As a fully Guix biased person, One thing I would really like to be in guix as coopi's mentioned is a standard file or directory for the guix stuff like nix have, i.e a single flake.nix or nix dir for everything but it might not be possible because you need to specify correct path of the scheme module to import them.
And for this lobsters post, only nix and lisp would suffice I think as they incorporated things the author talks about
I don't feel persuaded about removing linux (that's the only kernel they have in common! :P), but unix is likely out of place as you suggest.
I feel it'd be nice to also have a structured channel datatype that, like flakes, could help in automatically reasoning about what the channel provides like maybe
(channel
(operating-systems
(list my-vm))
(services
(list my-system-service)))
and a guix channel command to interact and help in creating new channels
Does Guix have an equivalent for overwriting pins of transitive dependencies, similar to .inputs.nixpkgs.follows in a Nix flake?
Also a lot of the author's description of Guix reminds me of Nix pre-flakes (no standardized entrypoint, channels). It seems like the same patterns don't become pain points in Guix do to having a type system and a real language though? Gives it a feel of alternate history if Nix had been betterdifferent language.
Does Guix have an equivalent for overwriting pins of transitive dependencies, similar to .inputs.nixpkgs.follows in a Nix flake?
What's that for?
Often it’s used purely to improve download size and reduce the amount of evaluation that Nix has to do. You’ll use it to force your inputs to use a single revision of Nixpkgs rather than each input having their own.
If I understood correctly, the goal is to avoid rebuilding the same package multiple times, then I think that's already the case for Guix by default. All the package definitions are sourced from a single commit for each channel (git repository). In general, the norm is not to have channels depend on each other, except on the main one.
Also, the Guix concept of grafting seems to berelated to what you're thinking of.
So this is a reply to everyone from Coopi
sorry for the issues mrow, coopi had done a change today meowrning but was unable to test it, due to work. turns out coopis javascript sux and there was an issue with it
Hesitant to upvote because of the usability issues pointed in other comments. (I use NoScript defaulting to JS disabled, so I didn't notice.)
However, this came to me at the right moment. We are leaning heavily into Nix at work and I have been struggling with flakes a bit, and I dunno, the explanation in the article was clearer than the stuff I've read before.
Coopi says
coopi is glad it works for u meoww!! it has tried its best to follow progressive enhancement, so that its site doesnt requite javascript or even css to be legible. well, it had fucked up the javascript part 😖 but atleast the progressive enhancement philosophy was working!! And now the javascript should also be fixed :D
You can lean heavily into Nix without the experimental flakes part. They are under-specified, limited in functionality, don’t compose well (follows a strong double-edge sword that strikes back at scale), & tend to send folks into abstraction hell to ‘work around’ design limitation as well as coupling flake concept into otherwise stable Nix code by accident. More folks should (re)discover classic Nix.
I hear you. Along the things you mentiond, I believe one of the hurdles I'm facing is the use of Flake Parts, which makes it harder for me to understand things.
However, we have two heavy Nix users leading the effort and they are very much into flakes. As a newcomer I can't have a strong opinion yet. I'll just try to contribute and learn for now.
I've said it a million times but I think Nix/Guix are likely the future (I except above docker build-style containers). But we're still very much in early adopter stage (IMHO), and I expect significant evolution in the ecosystem yet.
Yup, flake parts is abstractions on abstractions to get around flakes’ design issues :| I’ve seen some horrible stuff “at scale” where orgs are trying to set flake = false on all input to cut down on the explosion in lock file if even just one input doesn’t, but once you do that & suggesting overlays (the better compositional tool), what are folks getting out of it? Flakes often fall in the ‘bell curve meme’ with the simpleton & sage agreeing on simple setups. :P
Flakes are one big feature that solves a bunch of problems at once. Guix solves those same problems, but it does so with a collection of smaller, orthogonal tools that were mostly in place before flakes even existed.
I think it's fair to say that what flakes can do can be done with different tools in Guix, but it's worth noting that Nix also had (and still has) a set of smaller, orthogonal tools that can solve the same problems.
What flakes offers is a standard project entry point, and the ecosystem that this facilities (e.g. a registry) which as the post notes is what Guix doesn't have.
Guix users might decide they don't need a standard entry point, much as many Nix users have decided the same.
But suggesting that you can do flakes with a set of orthogonal tools reminds me of the argument that FreeBSD doesn't need OCI support, since you can already do all you need with jails. It misses the standardisation facilities an ecosystem.
I'm very keen on Guix (and have some contributions), and I'd like to see a comparison between what results in a build via guix time-machine with channels.scm take so much longer than changing a flake pin and doing a nix evaluation. I think I'd accept a 3x slowdown (5-10s to 15-30s), but when I've tried it it's been far from that.
This website is unusable on mobile in iOS. The page seems to load at the bottom and then immediately scrolls to the top, but as soon as I manually scroll down more than one screen, something triggers and it scrolls me right back up. Reader mode seems to work, but it loses highlighting and the otherwise neat fine styling.