add a nix flake to build just

[neunenak]

work in progress, I think it might be good to have a nix flake that builds the project for better integration into the nix ecosystem.

[casey]

Is this still something you're working on? I'm not sure I understand what a flake is for in this case, since Just is packaged in nixpkgs. And I thought a shell.nix, or something, was what you used for development. This is probably just ignorance on my part, since I am still confused by what a flake is 😅

[neunenak]

Is this still something you're working on? I'm not sure I understand what a flake is for in this case, since Just is packaged in nixpkgs. And I thought a shell.nix, or something, was what you used for development. This is probably just ignorance on my part, since I am still confused by what a flake is 😅

There are some benefits for people developing the project itself. Nix flakes are basically the modern, more-or-less-standard way to describe how to build and otherwise work with a software project in the nix ecosystem. In a flake.nix file you can define a devshell in the same way that shell.nix works, but also be more principled about pinning build inputs and do a few other things.

I think what I wanted this for was so that I could then define inputs in my own flake that look like `just.url = "github:casey/just", which would pin whatever git revision I wanted in a local lockfile and build exactly that version of just. Which lets someone using e.g. nix home-manager with flakes easily install the latest version without having to wait for a release or for the nixpkgs maintainers to update the official version. I got njbrake/agent-of-empires#309 merged into that project for basically the same reason.

Anyway I honestly forgot I had this draft PR open and now that I know claude can throw a basic build-rust flake.nix together pretty easily I'll probably ask it to fix whatever's broken about this PR and remove the draft.

[casey]

Sounds good, it seems useful.

[neunenak]

@casey this is ready for review now

[casey]

I have a limited ability to test Nix stuff. I have a shitty Nix VM with weird problems that I don't understand, and I don't want to install Nix on my Mac laptop, since the installer does weird stuff. That said, I tested it as best I could in my weird VM, and tried to simplify the flake as much as possible. cargo test doesn't work in nix develop, but that's because tests fail when fzf and vim aren't installed. But I think those are really separate issues, the tests shouldn't depend on them.

[neunenak]

I have a limited ability to test Nix stuff. I have a shitty Nix VM with weird problems that I don't understand, and I don't want to install Nix on my Mac laptop, since the installer does weird stuff. That said, I tested it as best I could in my weird VM, and tried to simplify the flake as much as possible. cargo test doesn't work in nix develop, but that's because tests fail when fzf and vim aren't installed. But I think those are really separate issues, the tests shouldn't depend on them.

Now that the merge happened nix shell github:casey/just should work on any NixOS machine or any Linux/MacOS machine with nix installed, as long as the flakes options is turned on. This worked for me just now and is mainly what I cared about.

As far as nix code formatting goes, there's several different standard formatters out there. I typically use alejandra, you might get slightly different opinionated decisions if you use a different one.

I think what might be going on with the tests is that in the nix environment, the cat binary is provided by the coreutils package and is one of a hundred or so symlinks to one coreutils binary that dispatches based on what binary name it was invoked with:

(nix:nix-shell-env) [greg@madoka just]$ which cat
/nix/store/74sind1d6vf2bfwd7yklg8chsvzqxmmq-coreutils-9.10/bin/cat
(nix:nix-shell-env) [greg@madoka just]$ eza -l /nix/store/74sind1d6vf2bfwd7yklg8chsvzqxmmq-coreutils-9.10/bin/ | grep -A 2 -B 2 cat
lrwxrwxrwx    - root 31 Dec  1969 basename -> coreutils
lrwxrwxrwx    - root 31 Dec  1969 basenc -> coreutils
lrwxrwxrwx    - root 31 Dec  1969 cat -> coreutils
lrwxrwxrwx    - root 31 Dec  1969 chcon -> coreutils
lrwxrwxrwx    - root 31 Dec  1969 chgrp -> coreutils

So that would imply that symlinking to cat like the two failing tests are doing won't actually work on a system where all coreutils binaries are already symlinks to one coreutils binary. Honestly, I thought that was how coreutils worked everywhere, but I just tried the same symlink thing the tests are doing on my arch linux system and that worked fine. Maybe this is a coreutils build flag or something.