Ignore workspace.default-members when running cargo install on root package of a non-virtual workspace#11067
Conversation
|
r? @ehuss (rust-highfive has picked a reviewer for you, use r? to override) |
55db927 to
08889ee
Compare
|
Ping @tedinski. Just checking in to see if you are still interested in working on this, or if you were seeking guidances. |
|
I hope to return to this if someone else doesn't beat me to a better solution, but I'm not certain what the best approach would be. The trouble with the "build with different My guess at a path forward there is perhaps to write a |
|
I think it would be fine to |
…ot package of a non-virtual workspace
08889ee to
7dc8be5
Compare
|
I've updated the PR to the suggested approach. The change was smooth, I just wasn't sure if wrapping it in an |
weihanglo
left a comment
There was a problem hiding this comment.
Looks good. Thank you for coming back taking care of this!
|
@bors r+ |
|
☀️ Test successful - checks-actions |
1 similar comment
|
☀️ 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`
| // and avoid building e.g. workspace default-members instead. Do so by constructing | ||
| // specialized compile options specific to the identified package. | ||
| // See test `path_install_workspace_root_despite_default_members`. | ||
| let mut opts = original_opts.clone(); | ||
| opts.spec = Packages::Packages(vec![pkg.name().to_string()]); |
There was a problem hiding this comment.
Looks like this is the cause of #11999. Would you be interested in working on a fix for it?
What does this PR try to resolve?
cargo install --gitbuildsworkspace.default-memberswhen it should not #11058Two observable behaviors are fixed:
cargo installwith--pathor--gitand specifically requesting the root package of a non-virtual workspace,cargo installwill accidentally buildworkspace.default-membersinstead of the requested root package.default-membersdoes not include the root package, it will install binaries from those other packages (thedefault-members) and claim they were the binaries from the root package! There is no way, actually, to install the root package binaries.These two behaviors have the same root cause:
cargo installeffectively doescargo build --releasein the requested package directory, but when this is the root of a non-virtual workspace, that buildsdefault-membersinstead of the requested package.How should we test and review this PR?
I have included a test exhibiting this behavior. It currently fails in the manner indicated in the test, and passes with the changes included in this PR.
I'm not sure the solution in the PR is the best solution, but the alternative I am able to come up with involves much more extensive changes to how
cargo installworks, to produce a distinctCompileOptionsfor every package built. I tried to keep the new workspace "API"ignore_default_members()as narrowly-scoped in its effect as possible.Additional information
The only way I could think this behavior change could impact someone is if they were somehow using
cargo install --path(or--git) and wanting it to actually install the binaries from all ofdefault-members. However, I don't believe that's possible, since if there are multiple packages with binaries, I believe cargo requires the packages to be specified. So someone would have to be additionally relying on specifying just the root package, but then wanting the binaries from more than just the root. I think this is probably an acceptable risk for merging!