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

Ignore workspace.default-members when running cargo install on root package of a non-virtual workspace #11067

Merged
merged 1 commit into from
Jan 18, 2023

Conversation

tedinski
Copy link
Contributor

@tedinski tedinski commented Sep 9, 2022

What does this PR try to resolve?

Two observable behaviors are fixed:

  1. When running cargo install with --path or --git and specifically requesting the root package of a non-virtual workspace, cargo install will accidentally build workspace.default-members instead of the requested root package.
  2. Further, if that default-members does not include the root package, it will install binaries from those other packages (the default-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 does cargo build --release in the requested package directory, but when this is the root of a non-virtual workspace, that builds default-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 distinct CompileOptions 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 of default-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!

@rust-highfive
Copy link

r? @ehuss

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 9, 2022
@tedinski tedinski force-pushed the install_workspace_root branch from 55db927 to 08889ee Compare September 9, 2022 20:23
@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 Oct 31, 2022
@weihanglo
Copy link
Member

Ping @tedinski. Just checking in to see if you are still interested in working on this, or if you were seeking guidances.

@tedinski
Copy link
Contributor Author

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 -p options" approach is that the CompileOptions isn't a clonable type, and ultimately (via BuildConfig) seems to contain some things that aren't clonable.

My guess at a path forward there is perhaps to write a clone_as_template method to both these types that asserts that certain problematic fields are None (and not Something unclonable). (I'm assuming we don't want to add a Clone implementation that's partial and might fail, hence the ad-hoc method.) Then we could clone and mutate the initial CompileOptions for each build, letting us (effectively) set -p appropriately for each one.

@ehuss
Copy link
Contributor

ehuss commented Jan 7, 2023

I think it would be fine to #[derive(Debug, Clone)] on CompileOptions and BuildConfig, and just wrap rustfix_diagnostic_server in an Arc (as in rustfix_diagnostic_server: Arc<RefCell<Option<RustfixDiagnosticServer>>>). Can you say if you ran into any problems with that? I think it generally should be a one or two line change.

@tedinski tedinski force-pushed the install_workspace_root branch from 08889ee to 7dc8be5 Compare January 13, 2023 00:15
@tedinski
Copy link
Contributor Author

I've updated the PR to the suggested approach. The change was smooth, I just wasn't sure if wrapping it in an Arc was the right approach to take, so that was helpful.

@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 14, 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.

Looks good. Thank you for coming back taking care of this!

@weihanglo
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jan 18, 2023

📌 Commit 7dc8be5 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 18, 2023
@bors
Copy link
Contributor

bors commented Jan 18, 2023

⌛ Testing commit 7dc8be5 with merge 23424fd...

@bors
Copy link
Contributor

bors commented Jan 18, 2023

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 23424fd to master...

1 similar comment
@bors
Copy link
Contributor

bors commented Jan 18, 2023

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 23424fd to master...

@bors bors merged commit 23424fd into rust-lang:master Jan 18, 2023
@tedinski tedinski deleted the install_workspace_root branch January 18, 2023 16:37
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`
@ehuss ehuss added this to the 1.68.0 milestone Jan 28, 2023
Comment on lines +171 to +175
// 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()]);
Copy link
Contributor

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?

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.

cargo install --git builds workspace.default-members when it should not
7 participants