Cargo2nix parses Cargo.lock and produces a Cargo.nix file that builds with an overlay.
The big feature for this release will be independent packaging, something that is necessary to nixify arbitrary repositories. The updated cargo version is also critical to parse newer lock files, making cargo2nix modern and able to catch up with Rust ecosystem movement.
Currently I’m only up against one issue on Mac. While cargo build works in the project nix shell, the nix build or --pure shell have been failing against a missing xcrun. I only verify builds on mac, so this is a bit foreign to me. You can hit the same issue by running nix-build -A package.bin with the PR code. In any case, some more maintenance bandwidth is of course welcome.
I think after 0.9 and collecting some more feedback from user issues that may pop up, it’s time to look at the architecture again and consider the overall landscape of cargoSha256 and naersk etc, as well as some newer Rust libraries for working with lock files like guppy. It may turn out that some of the work Cargo2nix became responsibility for in early releases is no longer necessary.
In the end, I think we just want:
- easy to provide (and automatically where possible) native, non-Rust deps
- reproducibility
- configurability that works with cargo rather than taking it over
- efficient caching for CI & local dev speed
- do as little work as possible and delegate to cargo more for better maintenance turnaround