-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
rustPlatform.importCargoLock: add support for v1 lock files #215629
Conversation
v1 lock files (generated by default by Cargo versions 1.40 and below) use a single table, `metadata`, to store the checksums of packages. The primary motivation for doing this now is that we're considering vendoring all Cargo lock files in Nixpkgs, some packages still use it (e.g. cargo-asm), and adding support for it doesn't increase the complexity of the function. No matter the outcome of the vendoring discussion, this is a nice thing to have because Cargo still supports v1 lock files.
@ofborg build tests.importCargoLock
Yes, this is foreshadowing (sorry); I'll be posting the details relatively soon, so we can actually have this discussion. I want to land this either way, though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, that was easier than I expected
assert lib.assertMsg (checksum != null) '' | ||
Package ${pkg.name} does not have a checksum. | ||
Please note that the Cargo.lock format where checksums used to be listed | ||
under [metadata] is not supported. | ||
If that is the case, running `cargo update` with a recent toolchain will | ||
automatically update the format along with the crate's depenendencies. | ||
''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I should adjust the message to say something like "the lock file may be corrupted, you can generate one with ...", instead of now just leaving it vague?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also does beg the question of why v1 support was intentionally omitted from the initial implementation -- is there some issue we may run into? I haven't run into anything in my limited testing, at least, so I hope that's not it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving it as it is lgtm. I think suggesting running cargo update
could be helpful, but I don't think we should say it might be corrupted, since the issue is probably more likely to be impoCargoLock
instead of Cargo.lock
Description of changes
v1 lock files (generated by default by Cargo versions 1.40 and below) use a single table,
metadata
, to store the checksums of packages.The primary motivation for doing this now is that we're considering vendoring all Cargo lock files in Nixpkgs, some packages still use it (e.g. cargo-asm), and adding support for it doesn't increase the complexity of the function. No matter the outcome of the vendoring discussion, this is a nice thing to have because Cargo still supports v1 lock files.
Things done
nix-build -A tests.importCargoLock
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes