Hackathon: Recreated build with Nix

[mserranom]

This is the result of a Hackathon experiment with https://nixos.org.

Note: these are the impressions after a few hours being introduced and fiddling with nix, take it with a pinch of salt.

Feel free to checkout the branch for testing, should work straight away in a development environment.

What is Nix?

Nix is a package manager for Unix systems (sort of apt, rpm) that aims to create deterministic environments.

To sum it up, it tries to solve a situation in which your Dockerfile that starts with:

FROM node
RUN apt-get update && apt-get install nodejs

will create a completely different image (or even fail) when you build it 6 months from now.

How is it different from apt?

We found the manual a bit hard to understand, but that's likely caused by the fact that you need to change your mindset. While apt or rpm kind of work the same way, nix does things in a different way.

I'd say the main difference is that packages are scoped. What that mean is:

1. You can installing packages with nix-env -i the same way you do with apt install. But if you install 2 packages, there's no guarantee they can speak to each other.
2. If you want multiple packages to work together (like in this module, where for some obscure reason python is required during npm install) we need to define them in the same shell.nix file, which will create an isolated shell where only the dependencies defined as buildInputs are available.

The Good

It actually works. Once the initial perplexity passes you get to understand why it works this way.

The bad

1. Obscure error messages, it took as time to resolve initial problems.
2. Documentation. It's not poor, but it's a bit confusing for new starters.
3. I feel it has an underlying problem with shells. If you see the shell.nix file, we're not specifying versions, which makes it not deterministic (which would be the main selling point!!). You can actually solve this problem, but in a far than elegant way (long github thread here).

Should we migrate at some point?

Probably not, but if we're struggling with reproducibility, might be worth checking again.

[das7pad]

My 2cents:

The Dockerfile shown in the PR body is utterly broken - just pull the docker image for node and you get the most recent version of node. One could pin the node base image via its' SHA256 to always get the same image.
With a package-lock.json/npm-shrinkwrap.json the build is almost deterministic in terms of versions of packages and their dependencies. With the exception of NPM allowing to publish a package twice or deleting packages that a malicious - that's out of our control and pretty rare.

The proposed Dockerfile is not much better, or even worse. There is no pinning of channel/package versions - which node version will you get, node 6,8,10,12,sha? and why did you remove the npm-shrinkwrap.json from the image? all the node_modules are specified with loose versions now.

[mserranom]

@das7pad Unfortunately not all the context of the hackathon can be included in the PR (that's why it's a draft), but your analysis is correct. I'm closing this since we're done with the research.