New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
treewide: fix cargoSha256 (again) #76060
Conversation
carnix is worse at the moment due the large amounts of nix expressions it generates. There is no alternative atm. |
d7363d6
to
5ac75b1
Compare
5ac75b1
to
7c9b60e
Compare
Why did the rustc update cause |
I'm also curious why this change didn't affect all rust packages. For example, it doesn't look as though |
Why did the rustc update cause `cargo vendor` output to change though?
What's the root cause here?
It looks like Cargo.lock files are no longer excluded. So only the
packages with dependencies containing Cargo.lock would have changed.
At least, that's what's changed for the one I looked at (rsclock, whose
vendored autocfg now includes Cargo.lock).
|
Wow really? That seems really odd, because I thought Cargo.lock was intentionally and explicitly excluded from dependencies. |
Wow really? That seems really odd, because I thought Cargo.lock was
intentionally and explicitly excluded from dependencies.
Yep. You can confirm yourself by building rsClock.cargoDeps before that
commit was merged from staging-next, and after, and comparing with
diffoscope.
It might not be that Cargo.lock specifically is now included, though.
Maybe there was some other change to inclusion logic made that just
happened to manifest as Cargo.lock beginning to be included in this
case.
|
Motivation for this change
Previously: #62047
This time the change in
cargo vendor
output was caused by a4fc84d.I hope that some time soon we can ban
buildRustPackage
from Nixpkgs.Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @