Add nix flake

[voidus]

This enables building via nix build and running via nix run github:siddhantac/puffin (once merged)

Putting this here as a proposal and space for discussion. It is not exactly zero-cost:

• For releases, the version should be adjusted. This doesn't really have any effect though, so it could be skipped.
• Whenever the dependencies change, the vendorHash needs to be updated or the old dependencies will be used if cached. (I think)
  In practice, this means replacing the vendorHash with an empty string and running nix build, this will show the correct vendorHash like so:

 > nix build                       
warning: Git tree '/home/voyd/Coding/puffin' is dirty
warning: found empty hash, assuming 'sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
error: hash mismatch in fixed-output derivation '/nix/store/rncp1mikj8nmy8ai56crnwk0pdca6d50-puffin-git-go-modules.drv':
        specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
           got:    sha256-XfsGXh9nz+QJEAqtw/BfzHhSVje6q0KLsVg1ZQ6fN4U=
error: 1 dependencies of derivation '/nix/store/s6arm30f9rxfxw3c4s3nkis0an7zr8j5-puffin-git.drv' failed to build

The sha is basically used as a cache key, so if a new version in which the vendorHash wasn't updated is built on a system that already has the old dependencies cached, it will wrongly use the cache.
An obvious way to prevent this would be to run the build in the pipeline, I'd be happy to add that if that would tip the scales for you, but it's going beyond my personal needs so I'll wait for your thoughts on this.

Depending on how deep you want to get into this, nix could also be used to define the development environment and so on of course, but I was interested in this and was missing this part because it allows me not to think about compiling the application.

[siddhantac]

I don't have any experience with nix. Please give me some time to review this.

Could you explain how this would change the release process? Or is the change limited to the 2 nix files?

[voidus]

Of course, take your time. I think it would also be reasonable to just leave this open and see if there is more demand or how your thoughts develop.

The nix file is not included in the go release, so all your existing processes still work and will keep working even if the flake wasn't updated at all.

To keep the nix part working, you would have to do these steps every time a go dependency is added, removed or updated:

1. Open the flake.nix file and change vendorHash = "sha256-..."; to vendorHash = "";
2. Run docker run --rm -v $PWD:/work nixos/nix nix --extra-experimental-features 'nix-command flakes' build /work in the repository. This will print something like this at the end:

error: hash mismatch in fixed-output derivation '/nix/store/rncp1mikj8nmy8ai56crnwk0pdca6d50-puffin-git-go-modules.drv':
       specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
          got:    sha256-XfsGXh9nz+QJEAqtw/BfzHhSVje6q0KLsVg1ZQ6fN4U=
error: 1 dependencies of derivation '/nix/store/s6arm30f9rxfxw3c4s3nkis0an7zr8j5-puffin-git.drv' failed to build

3. Put the "got" sha as vendorHash into flake.nix.

Re-running the docker command now succeeds. (It's not very verbose though, but it ends with something like building '/nix/store/5kna0s40lj178dqkizdxkzwv9mw7y7a6-puffin-git.drv'... and no error message)

Using docker allows you to update it without having nix installed on your system, but prevents caching since the container is discarded after the build. That said, on my system with a good uplink it takes about 23 seconds.

---

Having said all of this, if I were you, I wouldn't merge this unless you're interested in getting into nix. I think it's perfectly fine to leave this open or even close it and let it be an artifact of this discussion. Either way, it will provide you and other interested people an example of how to do it.
This is not required for nix/nixos users to user this application or for it to be included in the nix package repository, so don't feel pressured in any way :)

[siddhantac]

Thanks for the detailed explanation! I would like to make the application as easy to use as possible for everyone, however adding a new release pipeline which deviates from the usual process might be a bit much at this stage. I do appreciate the effort and your understanding that this may not be high on the priority list to merge at the moment.

Based on the steps you mentioned, it would be great if it could be automated and triggered by make. If you provide a script that can setup the nix stuff automatically I'd be open to the idea of including it as an optional installation method (with a disclaimer that I haven't tested it personally).