-
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
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 |
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 --git
buildsworkspace.default-members
when it should not #11058Two observable behaviors are fixed:
cargo install
with--path
or--git
and specifically requesting the root package of a non-virtual workspace,cargo install
will accidentally buildworkspace.default-members
instead of the requested root package.default-members
does 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 install
effectively doescargo build --release
in the requested package directory, but when this is the root of a non-virtual workspace, that buildsdefault-members
instead 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 install
works, to produce a distinctCompileOptions
for 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!