0319eccab39512bf55afa1536515c21134a1dbd0 should explain why, at least in the commit message, as it does technically work. I assume you just want to discourage its use?

Well, with cargo 1.68 and above we can not rely on it being reproducible with git dependencies, as there is extended logic involved now which might change in future versions, so we would have to regenerate the FOD hashes on every update.

The assumption is that cargo vendor is still reproducible when no git dependencies are involved.

Please re-read my comment -- that's exactly what I'm trying to say; it technically works, but we don't want anyone to actually use it. This should be made more clear, at least in the commit message, IMO.

There are several lockfiles committed without a corresponding nix package change?

e.g:

squeekboard/Cargo.lock
gnome-podcats/Cargo.lock
emblem/Cargo.lock
rnote/Cargo.lock
citations/Cargo.lock
newsflash/Cargo.lock
warp/Cargo.lock

Nixpkgs size increase of this PR is ~5% before compression, ~6% after compression.

$ fd '^Cargo.lock$' -X cat | wc -c
8.8Mi

$ git archive --format=tar HEAD~3 | wc -c
162600960
$ git archive --format=tar HEAD | wc -c
170997760

$ git archive --format=tar.gz HEAD~3 | wc -c
34881234
$ git archive --format=tar.gz HEAD | wc -c
37023424

There are several lockfiles committed without a corresponding nix package change?

good find, these should be fixed now

I have run nix-review to ensure that everything still builds.

These packages are already broken on master: fedigroups, habitat

Should I move the jumpy changes to #221921? Didn't see it when I was updating jumpy, sorry

oh cool that will work too

Noticed a spike averaging ~6.5 seconds in eval times at nixpkgs. On bisecting found:

Preceding commit to this PR:

• 2f0ff93 Merge pull request #222585 from fabaff/yara-bump
  • real 1m8,129s
    user 1m5,506s
    sys 0m2,620s

At this PR:

• f8cbc3c tree-wide: convert rust with git deps to importCargoLock
  • real 1m14,646s
    user 1m12,097s
    sys 0m2,546s

Command used for testing:

• time nix-env --query --available --out-path --file ./. > /dev/null

Also around 10GB of RAM on x86_64-linux. Haven't compared what we had before.

That's really weird, considering that in #217084 we found that converting all Rust packages rather than just ones with git deps had almost no impact on CPU time, and a similarly low impact on memory. cc @winterqt

OfBorg also found a much bigger evaluation performance difference than we were expecting from Winter's research: https://github.com/NixOS/nixpkgs/runs/12279178729

@yu-re-ka apologies if this has been answered somewhere, but is there a reason for not using Cargo.lock from ${src}/Cargo.lock ( where possible of course )

@yu-re-ka apologies if this has been answered somewhere, but is there a reason for not using Cargo.lock from ${src}/Cargo.lock ( where possible of course )

I think I've found answer,

during evaluation because the option 'allow-import-from-derivation' is disabled