GNU Guix package definitions for Gov.uk software and systems
github.com
github.com
https://github.com/alphagov/govuk-guix/issues/32#issuecommen...
I think it's important for us to move on in this discussion, so I'm going to reject this RFC.
This RFC proposes to use the govuk data tool to aid people in getting local development repo. However, the generation task of govuk data uses govuk-guix, which is a personal project built by Chris. We, as tech leadership of GOV.UK, have decided not to add guix to the GOV.UK stack.
There's a lot of value in the example of the guix data tool and this discussion. We'll make sure that it informs the discussions we're having right now about work on the GOV.UK developer environment for next quarters.
https://github.com/alphagov/govuk-rfcs/pull/101#issuecomment...
So, it seems to be once person's project and the gov.uk leadership seem to have rejected Guix. Still a shame though, Guix and Nix are great for reproducibility and setting up development environments. But I also understand that they don't want to introduce Guile Scheme, which most of their developers will not have a background in.
I was replying to a comment that, if I understand correctly, was suggesting "porting" Guix so that packages could be defined in Ruby instead of its native Guile, for the purposes of maintainability. But I may not have understood correctly, because I don't see how anyone could think that would improve maintainability. Hence the question.
It doesn't do the functional dependencies aspect well, but it is the package manager for macs.
Morph can't create machines for you - it doesn't have any backends except for SSH. It means fewer dependencies but you need to create targets manually or with something like Terraform. I've only used 'libvirt' and 'none' backends with NixOps and even wrote a 'dumb' backend that unlike 'none' backend wouldn't generate and store SSH keys in state but respects .ssh/config.
One feature of morph is really nice - declarative health checks that are run after the deployment automatically or can be triggered manually.
I also find it easier to explain to not-that-technical people as it basically requires one or two commands.
For the reference: https://github.com/DBCDK/morph
Oh, that's really a nice feature! I use NixOps for managing some personal hosts and one work VM, but the local state is annoying.
(also, we're hiring, if anybody interested in nix near Copenhagen is reading this)
https://github.com/alphagov/govuk-guix/issues/32#issuecommen...
What is Guix's main selling point?
I personally like Nix's syntax better than a lisp, but that is just a preference.
The core of how they operate is the same. Just look at their build/ci system.
It's also much more than a matter of syntax: see the great explanation at https://news.ycombinator.com/item?id=18910683 .
That rewrite is bring new features, differences, and makes them not compatible with each other. However, as they started off with the same code to me they will always be a fork. While something can evolve to something that is fully independent, it doesn't change it's origin. Also a fork is not bad word. Many successful "forks" become more popular than the original.
To this day guix still uses the nix-daemon code, which is written in C. And they build system they used was hydra, written in perl. In fact http://hydra.gnu.org used to say "download nix package". for everything. Cuirass is very recent, but you can still see that it still looks extremely similar to Nix's hydra.
I think guix still has better porcelain (cli).
Nix has much better discoverability and readability. I was going to show different files, however gnu.org NS servers seem to be down.
Most importantly it isn't a competition. These two products existing only benefit each other as new ideas between them flow both ways.
This is a good starting point:
Also, nix/guix are somewhat lower-overhead ways to build a system for local development than containers.
So Guix gives you reproducibility, provenance tracking, and hackability, but you can still "speak Docker".
It's quite an ambitious goal, and I'm still surprised it succeeded. Unlike docker, nix can't be naive about what's being built. For example, it has to understand the specifics of python and python packages, and build its own infrastructure instead of using the existing tools like docker.
This is the goal, but not actually the case. Nix/guix does many things to make reproducible outputs more likely, however people are very good at putting things in a package that are not deterministic, such as the build time down to the milisecond.
Guix 1.0 was released just two months ago. The announcement summarizes what it can do for you in these areas: https://guix.gnu.org/blog/2019/gnu-guix-1.0.0-released/ .