Add Nix environment

[sagikazarmark]

Overview

Nix allows creating reproducible environments. This PR adds Nix while keeping the rest of the tooling (mostly) backward compatible.

What this PR does / why we need it

"Works on my machine" is still a common answer in 2021 for environment specific issues during development.

Our current tooling setup (using Make) solves some of that by downloading the necessary tools, but not all of them (eg. Go).

Nix provides a more consistent environment, installing almost all dependencies (eg. Docker is still a problem on darwin). Installing Nix itself is fairly trivial, but the Make based tooling continues to work (with a slight change: make deps needs to be run manually now. Change is documented in README)

Special notes for your reviewer

Does this PR introduce a user-facing change?

Downloading tool dependencies now require manually running `make deps`

[JoelSpeed]

Nix isn't a project I've worked with before, but it sounds like it could be good for the project. In the past I've tried to make things reproducible by running them within containers, is there any advantage to the Nix approach over say, assuming our developers have docker/podman installed and running everything within a container?

[sagikazarmark]

Personally, I found running containers slightly inconvenient on macOS: it requires running a VM, IO performance is not always optimal and simply just running Docker Desktop without any containers can make my top notch MacBook Pro generate a lot of heat.

Nix provides a more "native" experience even on macOS. You cd into the project (given direnv is installed) and everything is magically configured, no need to build/update Docker images and you can just start working. If someone updates packages, you automatically get the new environment as soon as you pull the latest changes, no need to manually rebuild container images.

I've spent quite a bit of time with DX in the past couple years: tried using Make (see the current Makefile), containers, build systems (Bazel, Please) and now Nix. So far, Nix is my favorite.

I realize that's somewhat personal preference though which is why I left the current solution intact.

Some cons:

• The Nix language is famously hard to read, but that's probably okay for the dev env, it doesn't change that much
• Nix is probably not as widely used as Docker/Podman, but it's easy to install.

[nabokihms]

I'm not familiar with the tooling, but I definitely like the idea of improving dev environments 👍

I will try to test it and give some feedback.

[JoelSpeed]

Your argument seems reasonable and I know you've been experimenting with a few different choices. If we can settle on one preferred approach, and leave the existing make alone (or can it be called by nix? So as not to duplicate effort), then I think that's the best route for project

[sagikazarmark]

Nowadays I usually do the following: I use Nix for all my development workflows, but keep a make deps target around to download dependencies manually whenever possible. That makes up for the fact that most people don't use Nix, while the core devs can rely on Nix being there for them.

Maintaining a couple targets for dependencies in a Makefile is relatively cheap.

[sagikazarmark]

Any objections against merging this? Let's see if it sticks.

The old toolchain is still in place, so everything should work the same as before.

[nabokihms]

No objections. I agree to merge this and see how it will go.

[JoelSpeed]

Agreed, let's merge this and see how we get on

[sagikazarmark]

Cool, thanks!