Add a nix flake and development environment

[erikmannerfelt]

Nix is magic. Whether used in NixOS, as a standalone package manager, or in a nix/NixOS docker container, it improves repeatability and makes creating development environments a breeze.

I personally have my own nix config files that I copy over to xdem every time I develop. It's a bit of a hassle, so instead I suggest we have it in the repo directly. There is one drawback: it's yet another place to keep track of dependencies! I see that this might be a dealbreaker, at least as long as we don't have a solution for https://github.com/GlacioHack/geoutils/issues/230.

What this would look like is three new files in the root:

- flake.nix  # The package is defined for use in other nix repos, and the dev-shell is pinned to the lockfile
- flake.lock  # An autonomously managed lockfile for dependency pinning
- shell.nix  # Where the dev-shell is defined. It could be defined in the flake, but legacy nix won't work on that.

Links to nix-related stuff that shows its potential:

• Nix - Why You Should Give it a Try
• Why Should You Consider Using NixOS?
• A Tour of Nix Flakes

Advantages

• With one command (nix develop), a build environment is created that is the same across computers to the bit (it's checksum-validated).
• It's faster and easier than using conda/mamba
• It's one step closer to getting xdem/gu into nixpkgs, the largest software repo in existence.
• We could use it in our CI. Since the builds are identical between computers, it'll be much easier to debug problems. Also, since it's version pinned, CI won't randomly fail all of a sudden if a dependency suddenly breaks something.

Disadvantage

• Again, it's one more place to keep track of dependencies and versions.

One compromise would be to fix https://github.com/GlacioHack/geoutils/issues/230 before or just after so we don't create more problems than we solve.

Anyway, I'll leave it to you, @adehecq and @rhugonnet. What do you think?