simple-osd-daemons VS cargo2nix

I like the way crate2nix works. I have made a flake template for it here. Sometimes it requires a couple of overrides to fix some misbehaving crates (see https://github.com/balsoft/simple-osd-daemons/blob/master/flake.nix#L29 for an example of such overrides), but otherwise it's fantastic. It doesn't require any hash nonsense, it downloads and builds all the crates separately (unlike naersk or other solutions) so you get all the benefits of Nix (reproducibility and proper caching).

I have written a little tool that does something similar: it shows current volume, music track, battery percentage etc when they change (it's a bit like the OSD you see in DEs, but for your WM). Get the source here: https://github.com/balsoft/simple-osd-daemons

- Rust projects are built with https://github.com/cargo2nix/cargo2nix. We chose cargo2nix to get incremental builds, meaning that dependency builds can be shared between our Rust projects and that not all dependencies have to be rebuilt when adding/updating/removing dependencies from a project.

We used cargo2nix to generate top-level Cargo.nix file that we committed to the repository (we didn't allow generating nix files on CI for security and reproducibility reasons).

There's a cross compile example that works for at least 3-4 targets on Linux and uses proc macros. Pretty sure the situation you described is no more complex.

Release notes. Last announced release was 0.9.0.

Nix already solves this problem and can handle dependencies and building projects across a range of languages (including Rust via Cargo2nix) and reproducible machine configuration.

Building with nix, for instance with cargo2nix (https://github.com/cargo2nix/cargo2nix), could be safer if sandboxing is enabled.

cargo2nix