Guix has made it into Debian Unstable! This means Debian users can use Guix as a "userspace" package manager now! https://tracker.debian.org/pkg/guix
This is really wonderful! Debian and Guix both care deeply about reproducibility.
This could be a big win for user freedom on both (cotd ...)
Many important otherwise-FOSS applications are only available via black-box containers assembled from a mess of incompatible specific-language package managers. This is terrible.
However, Guix can be used to set up dev environments which *are* reproducible in userspace (cotd...)
For a long time this disconnect happened b/c distros that care about buildability/reproducibility were *disconnected* from new dev environments, which were done in userspace package managers.
But Guix comes with something like a universal virtualenv: "guix environment"! (cotd..)
Lots of people have good reason to run Debian. But now they can use Guix for dev, too!
And what is packageable for Guix tends to be packageable for Debian and vice versa.
Thus this could be a path out from one of the biggest problems user freedom faces: unbuildable software.
tl;dr: Ship every FOSS project with a "guix.scm" file.
These can be used to set up dev environments with
"guix environment -l guix.scm"
Projects built using Guix as a dev environment are free from the "binary-black-box-container-only" plague, healthier for user freedom!
@schmittlauch a shell.nix file, sadly, is not as much an assurance of freedom from the "binary-black-box-container-only" plague, sadly, as Nix ships plenty of software from binaries only.
@cwebber Does guix manage to build Signal desktop from source?
I once tried to build it myself but failed; even Gentoo just unpacks the Debian package :(
Apart from that: Yes, but then these are usually proprietary and marked as such.
I'm a bit jealous at guix for having a smaller bootstrapping base though.
> 1696 out of 1699 (99.82%) paths in the minimal installation image are reproducible!
https://r13y.com/
Don't enable nixpkgs.config.allowUnfree when building your thing and you're doing pretty well already.
Some language packaging imports pulls down binary things from their respective package managers as-is, but in racket2nix I build everything from source, and in my Copious Free Time when that's actually upstreamed into nixpkgs, I'll look around to see if other imports can be made to do the same.
In practice most of the things in those repos does come from source, but you have a point that there is no guarantee, especially when it comes to npm and rubygems.
@notclacke @schmittlauch Just to be sure, this looks like reproducible as in, you get the same result running the same package. If I can tell correctly, the metric they're using would list the npm packages as "reproducible" if they both unpack the binaries the same way as their inputs, since this command doesn't seem to track whether or not the package *is* fully built from source?
But glad to see it.
When I talked to Nix people at guix@FOSDEM two years ago they were very interested in @janneke 's work on the seed, and had branches of nixpkgs in progress that would make use of it. I don't know if any of that made its way into main finally.
My point is that Nix as a community may not be as focused and unified on reproducibility and traceability as Guix is, but there are definitely people in the community that want it, and it's going in that direction more than it isn't.
Interesting! Are binary blobs something guix.scm can safeguard against technically (as opposed to by convention/culture)?
@Sandra @schmittlauch It's convention/culture. Guix takes a firm stance for everything that goes into core.
@cwebber Thank you.
So
@schmittlauch a shell.nix file, sadly, is not as much an assurance of freedom from the “binary-black-box-container-only” plague, sadly
doesn’t necessarily make sense.
Not that I don’t love writing up some Scheme files.
@Sandra @schmittlauch Some conversation happened afterwards; the impression I have now is that Nix's core is not as much focused on "building from source", so some packages you get might actually just be binaries only... but other participants in this thread have shown that's improving after I made my original post. So there's a lot of room for optimism there.
@cwebber (Wow, so easy to miss things here on Fedi. Thank you for your patience re that.)
I got confused; your position would make sense if it was “What do I choose, NixOS vs Guix” but since you said in the context of Debian: “Ship every FOSS project with a “guix.scm” file” and that doesn’t necessarily do anything that a shell.nix file wouldn’t do.
Again, not that Scheme isn’t a nicer language, it is.
🇳🇱
@cwebber I love the idea of Guix and I came really close to using it. Honestly though when I heard that none foss orijects would be strictly forbidden from inclusion from their package manager, however, I dropped the whole idea. I do recognize that 3rd parties can of course maintain their own repositories for that, but it concerns me as I doubt the tools will be there to make that easy and I highly doubt there will be well maintained repositories of that type.
I still love the idea of Guix though and maybe ill get lucky and someone will fork it who is a bit more liberal in those regards.
I also think its a good reason not to include a guix file, as it locks you into an ecosystem that is committed to certain limitations up front.
@freemo @cwebber hey there! Some info you might find helpful. The tools for independently hosting your own Guix packages and extensions get lots of love and there are already a number of well-maintained outside forks, including mine. Forking Guix is easy. I wrote recently about how its design intentionally frees users from dependence on upstream maintainers and provide an inclusive mechanism for all business models & licenses: https://www.ryanprior.com/posts/what-is-guix-really/#headline-10
Well if that is your expiernce I'm willing to give it a second look and try it out. Thanks for that!
@cwebber do you have any links to good examples I could steal of guix.scm files?
@fincham Haunt has a nice example https://git.dthompson.us/haunt.git/tree/guix.scm
@cwebber I've been thinking about this for Fennel, right now the build dependencies are: make, a c compiler, curl, tar, and xz. if we added a git submodule for Lua itself it would just be the first two. I wonder at that point whether there'd be much benefit to adding a guix build?
@technomancy Maybe it's less useful than in some others, but it's at least helpful because then your contributors don't have to figure any of that out, they just run a command that figures it out for them.
@cwebber but like... are there any potential contributors (or heck even potential users) that don't already have make, gcc, and curl? it's already one "make" command away.
@technomancy Quite possibly true for your case :)
Most people aren't working with that level of minimalism ;)
@cwebber yeah. this is definitely a huge improvement over anything to do with containers.
@technomancy @cwebber I'm still in denial that containers exist
@technomancy
@cwebber
With packages being built in their isolated environments I don't have gcc or make in my user profile, and with packages linking directly to their dependencies I don't have curl installed either. Beyond providing a hacking environment a guix.scm file also makes it easy to build packages while hacking on them.
@technomancy @cwebber
I updated and tweaked fennel in #Guix a bit and created a guix.scm file. I was able to use it to cross-build to a bunch of different architectures, although some of them only worked with luajit. Possibly something misconfigured with our lua packages. https://git.sr.ht/~efraim/fennel/tree/guix.scm/item/guix.scm `guix build -f guix.scm` for the host architecture, `guix build -f guix.scm --target=aarch64-linux-gnu` for aarch64.
I wouldn't want to install and compile fennel manually on my phone, but if it were one "nix run" away in Nix-on-Droid I would consider that near-zero friction.
@cwebber or a `shell.nix` file ;)
Maybe even build it as a reproducible flake.