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.
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.
Using Ruby to attempt to build entirely reproducible and yet flexible software package definitions would be an anathema. There is a reason functional programming languages are chosen in these cases.
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.
Considering the ratio of professional, commercial, maintainable software written in Ruby to that written in Guile approaches infinity I fail to grasp your point about Guile being such an essential ingredient.
We're trying something similar - to provide a set of curated services with example deployments for cities or municipalities. We build on NixOS and use morph for deployment. Services include simple-nixos-mailserver, Redmine, Sympa, owncloud with LibreOffice Online and many more. If you're working on something similar or your're interested in helping with this cause feel free to contact me via email or IRC.
This is a really good idea. I love Nix and maintain a few packages there. I know govt deployments are really hard, and I've always thought Nix/NixOS/NixOps would be a killer combination. Hashed stateless configurations and easy rollbacks.
Not GP, but an advantage of a NixOS module is that it has a strongly-typed, explicit API for configuration options, whereas a Docker image would require documentation ala "set those 10 env vars" or "give a YAML config file that looks like this".
It doesn't maintain any state - NixOps uses SQLite database which makes it cumbersome to share with other devs.
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.
Avoiding local state is the primary reason we wrote morph, and the reason morph doesn't support provisioning hosts on AWS/GCE/.. is that we host everything in house. That makes morph simpler in many ways. :-)
(also, we're hiring, if anybody interested in nix near Copenhagen is reading this)
For software designed to be hosted in a datacenter (rather than distributed to an end user) is there a reason why Guix is better than some containerization framework? With things like Nix there's reproduciblity guarantees. With containers it (appears) simpler to package and reproduciblity ship your software.
I have read that comment and such before. However it is still a fork. It started off with the same code base, and is being rewritten in guile from the top down.
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.
Yeah but if I had the option of Docker or something nix based, why would I not choose Docker? Particularly as deploying to most Clouds is pretty easy if an app in already in a Docker Container.
You can easily build Docker images using Nix. Benefits: (1) reproducability, if you pin to a certain nixpkgs, you always get the same set of packages; (2) layers don't have to be full filesystem diffs; (3) the image only contains the computed closure. E.g. I produce Docker images an NLP program with Nix. The image only contains: glibc, tensorflow, my program, word embeddings, the model. No other system files or dependencies. Since the image build expression uses Nix expressions, I can also directly use the same models on my Linux workstation, Linux servers, macOS, etc. without Docker.
One advantage is that guix/nix only isolate dependencies. So, if I want two or more utilities to interact, I don’t need to bring in something like docker-compose or used network protocols, I just depend on both and write a script or something. This way, I can start with each service on its own container and then, as necessary, move two services into one container or whatever.
Also, nix/guix are somewhat lower-overhead ways to build a system for local development than containers.
Guix provides interoperability with Docker: the 'guix pack' command builds Docker images of applications, and 'guix system docker-image' builds images containing a complete system with services, etc.
So Guix gives you reproducibility, provenance tracking, and hackability, but you can still "speak Docker".
An already built container is reproducible in the same way that a binary artifact is reproducible. Nix is reproducible to its core, including hash integrity of every tool used to execute the build. Anybody should be able to build a bit-for-bit identical copy from scratch.
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.
> An already built container is reproducible in the same way that a binary artifact is reproducible. Nix is reproducible to its core, including hash integrity of every tool used to execute the build. Anybody should be able to build a bit-for-bit identical copy from scratch.
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.
Can someone familiar with this explain what it is? I've read the guix page and it's a package manager - so is this a graphical or command line tool to do UK government stuff (with no screenshots)? Or something else?
Guix is a tool for declarative and reproducible software deployment. You can view it as a package manager, but it's also an OS configuration management tool, a container image provisioning tool, and more.
https://github.com/alphagov/govuk-guix/issues/32#issuecommen...