Reproducible Development Environments with GNU Guix | Hacker News Reader

Reproducible Development Environments with GNU Guix

dthompson.us

84 pointsrev20 comments

Been using nix for a while for bookkeeping my development environments and it's been nice. The config syntax just is a bit unfamiliar so I'd be happy to check out Guix. The problem is that I also use non-free software and I haven't yet figured out how to set up my own Guix repo for that. Anyone got any luck with that?

if you want to set up a channel, just make a channel and put it anywhere (github is free).

if you do (in either nix or guix) let me know. I've been planning on doing something similar for non-free software for a while but to be honest it seems I don't have to use non-free software nearly as much nowadays.

That's nice, but why stop at being a package manager? Why not also replace the build tool (make et al.)?

If all the functional machinery is in place, this would be perfect for a build tool.

Because that means yet another build tool users have to maintain, check for security updates, etc. Packagers for people not using guix will need to start including it, etc, which will just add to the absolute excess of build tools out there. Currently installed on my system are bsd make, cmake, gmake, and scons, just to handle various software I've installed. Plus, you have samba in there that drags in Waf for its builds, and I know that there's some package out there I'm gonna want to poke at that's gonna wanna bring its buddies ant and/or nant in to party too. Unless the new and improved tool can understand all those tools, it's just gonna add to the mess.

Eventually this will probably happen in one way or another - although make isn't going to be replaced - it'll remain there for compatibility.

Currently, in a guix package, you specify how the package is built - and there are some predefined configurations built into guix, such as the gnu-build-system. It's perfectly possible to write your own build script in guile alone, or you can call other build tools.

In case you missed it, GNU Make already has Guile support built in - so you can already use it to augment your build process without throwing away make.

The real advantage of having a build process as part of Guix will come when we can throw away horrible hacks like pkg-config - since the Guix model of exact dependencies offers far more accurate information that pkg-config can guess, we'd have more reliability with less effort, and probably big performance gains.

What's the benefit of Guix compared to tools like Chef (https://www.getchef.com/) or Puppet(https://puppetlabs.com/)?

Guix is a package manager and a GNU/Linux distribution, whereas Chef and Puppet are configuration management systems that work with a number of different distros.

So, rather than using Puppet + Debian or something, you would probably just use Guix, because Guix has system configuration tools[0]. Guix (Nix, too) solves system management problems from the bottom, at the systems level. Other tools tack it on top of existing operating systems.

[0] https://www.gnu.org/software/guix/manual/guix.html#System-Co...

Guix seems to be a package manager. Chef/Puppet are configuration management tools. In short (from what I understand, I have only read about guix), you can use all of them to install software. But Chef/Puppet give you much more - distribution of configuration data, runtime search between machines, control over services / resources, etc. In practice you'd probably want to use one of them to install guix and run guix commands locally when setting up the hosts.

But then doing that would mean that you split a single system configuration through two different tools, right? I don't think it's ideal in practice.

I don't think guix does system configuration at all. And I don't mean "what software needs to be installed" configuration. I mean, configuration system that says "this is a staging environment, this app logs at DEBUG level via syslog, syslog gets configured to ship errors/exceptions to XXX, app uses local cache not cluster, credentials get pulled and decrypted from ABC".

This kind of configuration goes one level above package management, whether it's guix, apt, yum, pacman, or anything else.

Edit: you actually said benefits of guix in the original question - it gives you the way to make a localised installation of something you want. Chef/Puppet cannot be it on their own.

What Guix and Nix offer over puppet et al is a greater reliability in reproducing an environment - by eliminating the side effects that could lead to errors, or possible configurations and package combinations which have not been tested.

The fun part is that configurations can be treated exactly like packages and vice-versa. A "package" can depend on a specific configuration too. After you realize that package management and configuration management are not really disjoint ideas, it's the only sane way to think about reproducing software reliably.

>I don't think guix does system configuration at all.

It does, actually. Check out the documentation for details:

https://www.gnu.org/software/guix/manual/guix.html#System-Co...

Interesting; looks rather limited, but yeah, it's there.

One reason could be that the current version of both Chef and Puppet are licensed under Apache, and this is GPL licensed.

That's a good reason, but I don't understand if the use case scenario is the same or different. And if different, in what?

This seems to be more like a universal virtualenv than chef or puppet, just the way it's written up.

You are right, the 'guix environment' utility is a lot like virtualenv. However, Guix also has a system configuration utility.

A similar project, using docker and pexpect for dynamic and programmable - but auditable and deterministically built - images:

http://ianmiell.github.io/shutit/

Introducing: "Meta" a package manager for package managers.

To install, just type:

meta install meta

If I may indulge you, it's possible to 'guix package -i guix'.

Reply on news.ycombinator.com