build(rust): add support for Nix build environment

[DSharifi]

closes #1753

Edit:
Note to reviewers, the python environment is explicitly disabled in this PR, as I want to follow up with a proper setup that has the full pytest environment included.

[gilcu3]

Thank you, tested and worked on my env. Left some questions

EDIT: cargo-shear failed because probably you are using a newer version. Please sync versions with the ones used in CI, we can update them later in sync

[gilcu3]

at least on arch, the nix daemon must be running as well

[DSharifi]

Did you have to perform a step to start nix daemon?

[DSharifi]

Did you install it through AUR? I think it's recommended to use the script installer

[gilcu3]

nix recommends the script installer, and arch recommends their package

extra/nix 2.33.0-1 [installed]

and I prefer pacman to handle stuff, so I use the distro package, which requires the nix-daemon running.

[gilcu3]

we need to pin versions of these tools to follow ci, I tried cargo make and it failed because of that. new zizmor versions are less permissive. Same happens with these tools:

cargo-binstall
cargo-deny
cargo-insta
cargo-make
cargo-nextest
cargo-shear
cargo-sort

[pbeza]

It’d be nice to enforce in CI that these tools use the same versions as defined in .github/workflows/ci.yml. I can open a follow-up issue if we want to tackle this separately.

[DSharifi]

I'm adding it now. But it would be the wrong way to go about it to keep enforcing the 1;1 mapping.

If we want to maintain that, then CI might as well use nix

[DSharifi]

Pinned to CI versions except the three packages that are not on CI, so I'll go with latest versions here:

• cargo-binstall is not pinned to a specific version on CI, so keeping that one as is.
• cargo-insta (the CLI tool) doesn't exist on CI. The cargo dependency is same as in Cargo.toml.
• cargo-make not on CI

[pbeza]

I'm adding it now. But it would be the wrong way to go about it to keep enforcing the 1;1 mapping.

Why’s that? 🤔

If we want to maintain that, then CI might as well use nix

Why not unify the environment this way? 🤔 We’d finally be able to run CI checks locally in exactly the same way as on remote CI. I actually like this idea.

[DSharifi]

I'm adding it now. But it would be the wrong way to go about it to keep enforcing the 1;1 mapping.

Why’s that? 🤔

Because it adds maintenance overhead to have two update versions for packages in two places. It's easy to miss, and it also causes maintenance burden for whatever script we create to check this.

If we want to maintain that, then CI might as well use nix

Why not? 🤔

You're right to question why not. I 'd like to do this at some point. Then developers and CI have the exact same environment, but it's out of scope for this PR.

I wanted to start small with introducing a flake.nix file to just have a working dev environment as a first step of adding nix support.

[pbeza]

You're right to question why not. I 'd like to do this at some point. Then developers and CI have the exact same environment, but it's out of scope for this PR.

I created an issue for it: #1760.