-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Normalize git deps when doing cargo vendor
for resolving deps inherited from a workspace
#11414
Conversation
r? @weihanglo (rustbot has picked a reviewer for you, use r? to override) |
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.
Just had a skim on this. I am not sure how well we should maintain the compatibility of output of cargo vendor
between each versions. Maybe we should try hard not to churn the version control system too much.
BTW, I got this error while vendoring Cargo itself.
$ cargo vendor
Vendoring adler v1.0.2 (/home/weihanglo/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/adler-1.0.2) to vendor/adler
error: failed to sync
Caused by:
failed to copy over vendored sources for: adler v1.0.2
Caused by:
invalid inclusion of reserved file name Cargo.toml.orig in package source
dcaeaad
to
465a3f0
Compare
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.
Ooops. The latest update hit the same problem. It generates completely different Cargo.toml
from crates.io, which again churns the version control system. To reproduce, under cargo the project itself, run cargo +stable vendor
. Stage them with git add vendor
, and then cargo run -- cargo vendor
.
Sorry I didn't think about it carefully. We might go back and reuse things behind cargo package
, or anything doesn't change existing Cargo.toml
. 😞
4aa890e
to
92f1232
Compare
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.
Looks great! At least we reduce the affected radius to git dependencies. Thank you!
Should we prepend a header in the generated content telling that this is also generated, as what Cargo.lock
and registry source do?
92f1232
to
1316dc7
Compare
1316dc7
to
b64b605
Compare
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.
Thanks a lot. This is so much better than our initial plan!
I will go ahead and merge it :)
⚠️ Potential behavior change ⚠️
There was an overlook regarding workspace inheritance interacting with git dependency when doing cargo vendor
. After this PR, Cargo starts generating a normalized Cargo.toml
for git dependencies when vendoring. The normalized Cargo.toml
won't be identical to the original hand written one.
vendor
work similar to package
since it resolve…cargo vendor
for resolving deps inherited from a workspace
@bors r+ |
☀️ Test successful - checks-actions |
3 commits in a5d47a72595dd6fbe7d4e4f6ec20dc5fe724edd1..50eb688c2bbea5de5a2e8496230a7428798089d1 2023-01-16 18:51:50 +0000 to 2023-01-19 10:09:05 +0000 - Normalize git deps when doing `cargo vendor` for resolving deps inherited from a workspace (rust-lang/cargo#11414) - Ignore `workspace.default-members` when running `cargo install` on root package of a non-virtual workspace (rust-lang/cargo#11067) - Corrected documentation of how to cache binaries installed with `cargo install` in CI workflows (rust-lang/cargo#11592)
Update cargo 3 commits in a5d47a72595dd6fbe7d4e4f6ec20dc5fe724edd1..50eb688c2bbea5de5a2e8496230a7428798089d1 2023-01-16 18:51:50 +0000 to 2023-01-19 10:09:05 +0000 - Normalize git deps when doing `cargo vendor` for resolving deps inherited from a workspace (rust-lang/cargo#11414) - Ignore `workspace.default-members` when running `cargo install` on root package of a non-virtual workspace (rust-lang/cargo#11067) - Corrected documentation of how to cache binaries installed with `cargo install` in CI workflows (rust-lang/cargo#11592) r? `@ghost`
…se workspace inheritance Rust 1.64.0 added support for workspace inheritance, which allows for crates to inherit values such as dependency version constraints or package metadata information from their workspaces [0]. This works by having workspace members specify a value as a table, with `workspace` set to true. Thus, supporting this in importCargoLock is as simple as walking the crate's Cargo.toml, replacing inherited values with their workspace counterpart. This is also what a forthcoming Cargo release will do for `cargo vendor` [1], but we can get ahead of it ;) [0]: https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#cargo-improvements-workspace-inheritance-and-multi-target-builds [1]: rust-lang/cargo#11414
…se workspace inheritance Rust 1.64.0 added support for workspace inheritance, which allows for crates to inherit values such as dependency version constraints or package metadata information from their workspaces [0]. This works by having workspace members specify a value as a table, with `workspace` set to true. Thus, supporting this in importCargoLock is as simple as walking the crate's Cargo.toml, replacing inherited values with their workspace counterpart. This is also what a forthcoming Cargo release will do for `cargo vendor` [1], but we can get ahead of it ;) [0]: https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#cargo-improvements-workspace-inheritance-and-multi-target-builds [1]: rust-lang/cargo#11414
In #11192 it was noted that workspace inheritance causes vendored git dependencies to fail since
workspace = true
does not get resolved during vendoring.To fix this, it was suggested to make
cargo vendor
work similar tocargo package
since it resolves manifests before packaging them. There were problems with this potential solution, so it was decided to use aManifest
's "original"Cargo.toml
. This isn't exactly the originalCargo.toml
since{}.workspace = true
gets removed into_real_manifest
where the "original" is from. There were concerns that this would cause churn in the outputCargo.toml
. To get around this, we only use theManifest
's "original"Cargo.toml
if a git dependency is being vendored. This is because the bug from #11192 only affects git dependencies since published dependencies haveworkspace = true
removed before publishing.close #11192