treewide: use new cargo fetcher

[Bot-wxt1221]

TODO: @emilazy suggest my script should be reviewd independently and all output should be reduced.

She has mentioned that FOD hash attack is possible.

This is a tracking issue to replace #356862.

These are from old PR:

Already done. We should run nixpkgs-review to check if some package have different Cargo.lock when building and in nixpkgs, like veloren.

I have writen a script to update it automatically.

Now It can solve:

cargoLock = {
  lockFile = xxx;
  outputhahes = {xxx};
};

cargoLock.lockFile = xxx;
cargoLock.outputHashes = {xxx};

Script: https://github.com/Bot-wxt1221/cargo-rename

Usage:

Compile with gcc. Make sure fetch-cargo can be exec. Exec with a xx/pkgs/by-name/xx/xx/package.nix

cc #327063

#349360

Step to reduce:

1. Generate a file list with cargoLock:

rg "cargoLock" --files-with-matches > filewithcargoLock

cat filewithcargoLock | rev | cut -d / -f 2|rev > packagename

2. run update-all

useFetchCargoVendor

[Bot-wxt1221]

Now All PR have split nixfmt into one.

[Aleksanaa]

@emilazy do you agree with the step of changing to fetchCargoVendor first, before we investigate one lockfile mechanism?

[Atemu]

Sorry, when was this resolved?

[emilazy]

@emilazy do you agree with the step of changing to fetchCargoVendor first, before we investigate one lockfile mechanism?

Yes, I’m fine with that if others decide it’s a good idea (opinions on a treewide migration seemed mixed in #356862, but I have no objection myself) – my reviews were only to ensure that the PRs were not prematurely merged without someone reviewing the migration program’s logic and reproducing its results, as a mass change of FOD hashes across the tree is a worst‐case scenario for Nixpkgs supply‐chain attacks.

[Bot-wxt1221]

I'm sorry that I can't promise to have enough time for a long term to keep active in nix community. So I close it. The script is still here that anyone run it and review it.

[Atemu]

I think the one large lockfile approach would be desirable whether we have the cargo fetcher or not.

I'm sorry that I can't promise to have enough time for a long term to keep active in nix community. So I close it.

You're in the same place as many of us; everyone understands. It's totally fine to keep issues open or work unfinished for years. No worries.

Get back to it when/if you have time and motivation. If you know you won't personally do it any time soon, it's good to be explicit about that (as you've just done) so others know they're free to pick up where you left off.

[emilazy]

I think the one large lockfile approach would be desirable whether we have the cargo fetcher or not.

Agreed, of course, but I’m biased, and I don’t want to block incremental improvements on my moonshot :) (Though these days I refer to it as separate crate packaging rather than one big lock file since we wouldn’t actually have or want one gigantic Cargo.lock file.)