naersk has a track record of pulling in it's own nixpkgs and any follows constellations continuously cause problems (due to long lasting bugs in nix's follows implementation). This is why many repositories start switching to 21.11 upstream rust machinery (which can consume Cargo.lock files).
Piling up uncontrolled nixpkgs versions in flake lock files is not necessarily bad, per se, but it makes it increasingly hard for an operator to manage & audit this core dependency for about everything.
If my sentiment is mirrored I'd be happy to prepare a PR with a switch.
Hey! Thanks for opening this issue. In fact, we were thinking of eliminating naersk as well. We'd happily accept a PR which uses buildRustPackage with cargoLock. Feel free to go ahead 🙂
naersk has a track record of pulling in it's own
nixpkgs
and anyfollows
constellations continuously cause problems (due to long lasting bugs innix
'sfollows
implementation). This is why many repositories start switching to 21.11 upstream rust machinery (which can consumeCargo.lock
files).Piling up uncontrolled
nixpkgs
versions in flake lock files is not necessarily bad, per se, but it makes it increasingly hard for an operator to manage & audit this core dependency for about everything.If my sentiment is mirrored I'd be happy to prepare a PR with a switch.