Skip to content
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

Merged
merged 1 commit into from
Jan 19, 2023

Conversation

Muscraft
Copy link
Member

@Muscraft Muscraft commented Nov 23, 2022

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 to cargo package since it resolves manifests before packaging them. There were problems with this potential solution, so it was decided to use a Manifest's "original" Cargo.toml. This isn't exactly the original Cargo.toml since {}.workspace = true gets removed in to_real_manifest where the "original" is from. There were concerns that this would cause churn in the output Cargo.toml. To get around this, we only use the Manifest'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 have workspace = true removed before publishing.

close #11192

@rustbot
Copy link
Collaborator

rustbot commented Nov 23, 2022

r? @weihanglo

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 23, 2022
Copy link
Member

@weihanglo weihanglo left a 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.com-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

tests/testsuite/vendor.rs Outdated Show resolved Hide resolved
src/cargo/ops/vendor.rs Outdated Show resolved Hide resolved
src/cargo/ops/vendor.rs Outdated Show resolved Hide resolved
src/cargo/ops/cargo_package.rs Outdated Show resolved Hide resolved
@weihanglo weihanglo added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 8, 2022
@weihanglo weihanglo added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Jan 11, 2023
Copy link
Member

@weihanglo weihanglo left a 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. 😞

tests/testsuite/vendor.rs Outdated Show resolved Hide resolved
@Muscraft Muscraft force-pushed the vendor-use-package branch 2 times, most recently from 4aa890e to 92f1232 Compare January 18, 2023 16:54
Copy link
Member

@weihanglo weihanglo left a 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?

src/cargo/ops/vendor.rs Show resolved Hide resolved
src/cargo/ops/vendor.rs Show resolved Hide resolved
Copy link
Member

@weihanglo weihanglo left a 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.

Edit: relevant discussion on Zulip t-cargo

@weihanglo weihanglo changed the title fix(vendor): Make vendor work similar to package since it resolve… Normalize git deps when doing cargo vendor for resolving deps inherited from a workspace Jan 19, 2023
@weihanglo
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Jan 19, 2023

📌 Commit b64b605 has been approved by weihanglo

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 19, 2023
@bors
Copy link
Collaborator

bors commented Jan 19, 2023

⌛ Testing commit b64b605 with merge 50eb688...

@bors
Copy link
Collaborator

bors commented Jan 19, 2023

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 50eb688 to master...

bors pushed a commit to rust-lang-ci/rust that referenced this pull request Jan 19, 2023
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)
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 19, 2023
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`
@Muscraft Muscraft deleted the vendor-use-package branch January 25, 2023 15:29
@ehuss ehuss added this to the 1.68.0 milestone Jan 28, 2023
yu-re-ka pushed a commit to NixOS/nixpkgs that referenced this pull request Mar 18, 2023
…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
figsoda pushed a commit to NixOS/nixpkgs that referenced this pull request Apr 11, 2023
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot build vendored git dependency if it inherits info from a workspace
5 participants