get rid of naersk
blaggacao opened this issue · 1 comments
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 🙂