Add Nix flake

[myclevorname]

Warning: The test options::common::address::tests::resolve_should_properly_resolve_bind_address fails on my system, which is x86_64-unknown-linux-gnu running NixOS.

I turned this into a flake by request of @dgmcguire.

[chipsenkbeil]

@myclevorname Hi! Thanks for this. I'm aware of Nix and associated software, but no nothing of the flake file and format. Looking through it, there are multiple version references that I'm assuming I would need to maintain?

The version key is set to 0.20.0-unstable. There is no published crate or released binary with that version, so I'm assuming the -unstable is something specially handled by Nix? But that I'd need to update whenever I publish a new release? For an alpha release (not yet published) like 0.21.0-alpha.1, would this become 0.21.0-alpha.1-unstable for Nix?

Separately, I need to now maintain a Cargo hash. I'm not familiar with this based on the lock file. Is it a hash of the lock file itself?

Lastly, there's a list of targets that I'm assuming apply to Nix? Is this supposed to match our full triple target format? Or something specific to Nix? For example, we also offer aarch64 for Linux and support GNU and musl variants of x86 and aarch64 for Linux.

---

Also, ignore the linting errors. We use the latest Rust release's linter, and I haven't run a PR recently, so there was probably something additional added that I'll need to correct. Once I figure out the above questions, I can merge this in.

[myclevorname]

The version argument is completely optional, but I added it for some reason. When you update the cargo lockfile and run nix build, Nix will complain about cargoHash being incorrect. Set the value of cargoHash to whatever Nix expected the hash to be.

[chipsenkbeil]

The version argument is completely optional, but I added it for some reason.

Wait, so is it purely cosmetic? Just figuring out what I need to set it to, and if the -unstable is needed.

Set the value of cargoHash to whatever Nix expected the hash to be.

@myclevorname okay, so I need to have nix installed to figure out the hash? Thinking through how to automate this since I don't have it installed on any of my machines. Maybe there's a Github action that can run if the lock file changes, calculate the hash, and then use sed or something to update the flake file.

[myclevorname]

The version argument is only required when making a Nix package. It wasn't as smart idea for me to add it when this is a flake. There may be a Github action that supports Nix, so you may be able to update it using that.

[myclevorname]

As of right now, I am refactoring the flake to use flake-utils instead of hard-coding the targets in the flake.

[zDonik1]

What is currently blocking the PR? Would really love to have distant install on my NixOS system.

[myclevorname]

The only blocker is the failing test "options::common::address::tests::resolve_should_properly_resolve_bind_address" because Nix prevents packages from accessing the network at build-time. Right now, I am working on ignoring this test when Nix builds the package.

[zDonik1]

Oh I see thanks. I decided to disable all tests as a temporary workaround.

[myclevorname]

That sounds like a better idea.

[chipsenkbeil]

Would it be possible to get some nix deployment integrated into the release workflow, or a nix specific github workflow?

I don't use nix and therefore wouldn't be able to maintain the file properly, so anything we can do to automate it would be fantastic. Both on the file, and the deployment that you need me to do. Going back to my questions earlier about needing nix.

I need to have nix installed to figure out the hash? Thinking through how to automate this since I don't have it installed on any of my machines. Maybe there's a Github action that can run if the lock file changes, calculate the hash, and then use sed or something to update the flake file.

Anyone here familiar with github actions that are commonly used with nix?

[zDonik1]

Would it be possible to get some nix deployment integrated into the release workflow, or a nix specific github workflow?

I think it would be best to make it separate, and check for Cargo.lock changes on every commit. If the flake will not be up to date (there is a hash mismatch), users will not be able to use the flake, which kind of beats the point of having the flake.

I have looked through some of the nix actions none of them provide updating the hash in a flake.nix file.

The basic gist of what has to be done is the follows:

1. Check for updates to Cargo.lock on every commit
2. Try building with nix build which should give us the new hash in the error output. (will need an action to install nix)
3. Replace the hash in the flake.nix file
4. Make a PR or push directly to master.

We can use paths-filter for the first step, which should guarantee that Cargo.lock was changed for the rest of the steps.

Note that I am not very familiar with Actions.

[chipsenkbeil]

Thanks for the input, @zDonik1. I think the hard part is getting the hash programmatically. Is the messaging consistent when it fails to build? Is there no other way to leverage nix to output the hash reliably? I'll also dig around a bit to see, but once I know how to get that, shouldn't be hard to whip up an action to do this.

[zDonik1]

I have looked through the nix code to see how the hash is generated but no luck. Maybe you will have more success. But note that the hash is generated by serializing the input (or output, not sure which) directory into NAR and hashing that using sha256. there is a command you can try using nix hash path which supposedly takes a path, makes a NAR serialization, and outputs the hash, but I wasn't able to replicate the exact correct hash.

[myclevorname]

Here is what the output on my machine looks like if the hash was mismatched.

warning: Git tree '/home/clevor/Code/Contribute/distant' is dirty
warning: found empty hash, assuming 'sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
error: hash mismatch in fixed-output derivation '/nix/store/ppbx3q7a62kp1hw6gmyxqd6awliif7lr-distant-vendor.tar.gz.drv':
         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
            got:    sha256-mPcrfBFgvbPi6O7i9FCtN3iaaEOHIcDFHCOpV1NxKMY=

If there is an error with the hash, you should be able to extract the text hash mismatch. If you do find that specific error, you should be able to extract the hash. It should be of format got: sha256-hashOutput, where you extract sha256-hashOutput. Don't expect to always have four spaces.