Package for Nix; Add version subcommand

[LukeDSchenk]

This PR adds a new version subcommand that simply prints the iroh-ssh version. I added this so the program has something to pass a version check during a nix package build.

This PR also contains two files for creating a nix package of iroh-ssh. nix/package.nix will need to be updated with proper hashes, but this file won't actually build correctly until a 0.2.8 release has been made (0.2.8 is the proposed updated version that includes the version subcommand).

If you would like to test out that these files will work as intended once the release is made and the hashes are updated, you can go check out the main branch of my iroh-ssh fork. I have tested the build process there, pointing at my own 0.2.8 release.

If these changes are approved, I would like to open a PR into nixpkgs to get iroh-ssh added there.

[rustonbsd]

Hi @LukeDSchenk,

thank you for adding the version subcommand and the PR!

I have never worked with nix before, so please correct me on anything.

I replaced the cargoHash in the package.nix file with the nix computed hash (sha256-KZu4HA5E9R4sdBW5cdhyA5E2bo2YN2TPSKDlJuzDGnU=) from the last commit I made (765803e) and got it to successfully build.

In my understanding I now need the fetchFromGitHub github tag tar hash right? If so, could you recreate the 0.2.8 tag on your fork to the last commit (765803e), I will then add the hash from the created tag tar and make a final commit with the updated package.nix file. If that is all correct, I will merge and publish v0.2.8 to crates.io. Let me know if I understand correctly.

[LukeDSchenk]

So this morning I try to SSH into my NixOS server where I have been working on this, and I have some kind of weird network issue and can't SSH in. After trying all kinds of firewall checking, I just decided to try iroh-ssh instead and it works. Feels very affirming 😅

But yes, @rustonbsd I believe you understand correctly! I will get back to you shortly with the changes.

[LukeDSchenk]

@rustonbsd okay, I updated the hashes. I notice that when I make github releases on my own fork, the nix folder is not being included in the tarball. I am not exactly sure why that is, but it seems beneficial either way, because it's not important for someone to run the software. It also means that the tarball hash isn't changing as I change package.nix. I am a bit confused as to why that is though! We will have to make sure that is also the case here.

I believe that now, once the changes are merged and 0.2.8 release has been created in this repo, everything should work as expected.

[rustonbsd]

Hi @LukeDSchenk,

I think the new tag for v0.2.8 is still pointing to the old commit 999c2ef instead of 765803e.

I have this issue sometimes where github and vscode aren't super great with the tag updates if the tag already existed (in those cases I manually delete it on GH and push it again). Or maybe github is caching it on my end? Could you double check the tag and if it is still pointing to the old commit, update it? After that we are ready for release I think.

[rustonbsd]

Never mind, it seems to have just been a cache issue on my end. Now I can see it points to the right commit.

[LukeDSchenk]

@rustonbsd don't gaslight yourself, I went and fixed it 😂 I just hadn't told you yet

[LukeDSchenk]

I was having some issues with the build appearing to work on my server, but realizing it was actually using the old build that was cached. Because of that, I decided to try and build it on a different machine, and I am getting this error:

 > error: rustc 1.87.0 is not supported by the following package:
       >   homedir@0.3.6 requires rustc 1.88
       > Either upgrade rustc or select compatible dependency versions with
       > `cargo update <name>@<current-ver> --precise <compatible-ver>`
       > where `<compatible-ver>` is the latest version supporting rustc 1.87.0

I noticed that when you updated the deps, homedir didn't change, so I am not sure what it is. I am going to spend some more time figuring it out, probably not until later this evening.

[rustonbsd]

You are right, that is odd. Could it be that your first build environment had a newer rust version and homedir always required at least rustc v1.88?

Let me know what you find out, this is interesting!

[LukeDSchenk]

I thought that was the case too, especially after running rustup update and seeing that I hadn't updated this machine since about rustc 1.79, but even after that the error is here.

[LukeDSchenk]

From what I am reading, I think it has to do with the nix-channel I am using having an older rustc version included in it (which makes sense, based on when I installed nix on this particular machine). I think I am going to have to rework things just a little bit, but I see a path forwards and I think the end result will be more reproducible and fault tolerant than what we have here.

[LukeDSchenk]

Okay, @rustonbsd now I believe we are actually ready. I didn't end up changing the file other than updating the hashes to the re-created 0.2.8 release with the proper tags.

You can disregard my earlier message about having to rework it. I had to rework how I was building it on my machine, but further reading has made me confident that the package is actually as it should be. The TLDR of what I did was I made a Flake that would allow me to specifically set a rust toolchain version, since the nix setup I was using was slightly out of date.

Let me know if everything seems right on your end!

[rustonbsd]

I tested it both from local source and from your github release and both builds pass.

The only thing is that if the build.sh script is run from the repo root, the build fails, expecting the package.nix to be in the same folder, but I think that is fine, I like a clean build.sh, so we can leave it like it as is.

Just out of curiosity, would it break some nix convention to add a repo root check and adjust the build script or is the build.sh not part of any nix process and just for ease of use?

[LukeDSchenk]

Just out of curiosity, would it break some nix convention to add a repo root check and adjust the build script or is the build.sh not part of any nix process and just for ease of use?

You are right, build.sh is just for convenience. It's your repo, I'm in favor of any checks or conventions you wish to add 🫡

but please don't abuse my blind support

[rustonbsd]

• just finished up the Github release
• setup nix tag
• successfully build with nix on a fresh system from the main repo
• crates.io published: https://crates.io/crates/iroh-ssh

Thank you again for the PR!

[LukeDSchenk]

@rustonbsd you're very welcome! Thank you for your patience on this learning journey. I am going to see about getting this added to nixpkgs now 🙏