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

docs(ref): Index differences between virtual / real manifests #13794

Merged
merged 6 commits into from
Apr 25, 2024

Conversation

epage
Copy link
Contributor

@epage epage commented Apr 23, 2024

What does this PR try to resolve?

For a user to read the reference and to understand when each type of workspace might be right for them, they have to know to also read the section on Package Selection.

This reframes the section on needing to set resolver = "2" to being about differences when there isn't a root package and extends it to summarize a part of Package Selection, linking out to it. The hope is that this will make it all of the differences more discoverable without retreading too much of the same ground within Reference-style documentation.

Part of #13580

How should we test and review this PR?

Additional information

r? @weihanglo

@rustbot rustbot added A-documenting-cargo-itself Area: Cargo's documentation S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 23, 2024
Comment on lines 83 to 90
When there isn't a root package:

- [`resolver = "2"`](resolver.md#resolver-versions) must be
set explicitly in virtual workspaces as they have no
[`package.edition`][package-edition] to infer it from.
[resolver version](resolver.md#resolver-versions).
- Commands run in the workspace's directory will run against all workspace
members by default, see [Package selection](#package-selection).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel a bit disconnected with the previous paragraph. What about this:

Suggested change
When there isn't a root package:
- [`resolver = "2"`](resolver.md#resolver-versions) must be
set explicitly in virtual workspaces as they have no
[`package.edition`][package-edition] to infer it from.
[resolver version](resolver.md#resolver-versions).
- Commands run in the workspace's directory will run against all workspace
members by default, see [Package selection](#package-selection).
Some major differences bewteen root packages and virtual workspaces:
- In virtual workspaces, [`resolver = "2"`](resolver.md#resolver-versions) must be
set explicitly as they have no
[`package.edition`][package-edition] to infer it from.
[resolver version](resolver.md#resolver-versions).
- Commands run in the a virtual workspace's directory will run against all workspace
members by default, see [Package selection](#package-selection).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not quite seeing the problem.

When I look at the previous paragraph, it ends on the note of the role of virtual workspaces contrasted with root packages

This is typically useful when there isn't a "primary" package, or
you want to keep all the packages organized in separate directories.

I tweaked the leading line for the new section a little bit which now reads

By having a workspace without a root package,

Could you help me understand what challenge you are seeing in the transition?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that. It feels better now. I guess it is because that there is an extra term “primary package”, so root package is a bit far when mentioned.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is still something missing. The doc never explains that a root package is effectively a default workspace member.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was implied in the old "Package selection" wording by saying that the package for the current working directory is used. However, I think the current wording is up for misinterpretation and I'm tweaking it in hopes that it will be less confusing.

Nothing else in the files does despite it all being optional and this
will be clearer in a follow up when I specify the defaults.
This will make it easier to make future changes
The old statement that its a subset of `members` is incorrect because
some members can be inferred and not show up in `members`.

I tried to reword this to better convey the goal of what was being said
This also tweaks the wording to be clear that `default-members` always
apply in the workspace root, not just for virtual workspaces.
For a user to read the reference and to understand when each type of
workspace might be right for them, they have to know to also read the
section on Package Selection.

This reframes the section on needing to set `resolver = "2"` to being
about differences when there isn't a root package and extends it to
summarize a part of Package Selection, linking out to it.
The hope is that this will make it all of the differences more
discoverable without retreading too much of the same ground within
Reference-style documentation.

Part of rust-lang#13580
@weihanglo
Copy link
Member

@bors r+

Nice work!

@bors
Copy link
Contributor

bors commented Apr 25, 2024

📌 Commit 5f5e0fc 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 Apr 25, 2024
@bors
Copy link
Contributor

bors commented Apr 25, 2024

⌛ Testing commit 5f5e0fc with merge e91b58d...

@bors
Copy link
Contributor

bors commented Apr 25, 2024

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

@bors bors merged commit e91b58d into rust-lang:master Apr 25, 2024
21 checks passed
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 26, 2024
Update cargo

9 commits in c9392675917adc2edab269eea27c222b5359c637..b60a1555155111e962018007a6d0ef85207db463
2024-04-23 19:35:19 +0000 to 2024-04-26 16:37:29 +0000
- fix(toml): Remove underscore field support in 2024 (rust-lang/cargo#13804)
- fix: emit 1.77 syntax error only when msrv is incompatible (rust-lang/cargo#13808)
- docs(ref): Index differences between virtual / real manifests (rust-lang/cargo#13794)
- refactor(toml): extract dependency-to-source-id to function (rust-lang/cargo#13802)
- Add where lint was set (rust-lang/cargo#13801)
- fix(toml): Don't double-warn when underscore is used in workspace dep (rust-lang/cargo#13800)
- fix(toml): Be more forceful with underscore/dash redundancy (rust-lang/cargo#13798)
- Fix warning suppression for config.toml vs config compat symlinks (rust-lang/cargo#13793)
- Cleanup linting system (rust-lang/cargo#13797)

r? ghost
@epage epage deleted the workspace branch April 27, 2024 01:09
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 27, 2024
Update cargo

9 commits in c9392675917adc2edab269eea27c222b5359c637..b60a1555155111e962018007a6d0ef85207db463
2024-04-23 19:35:19 +0000 to 2024-04-26 16:37:29 +0000
- fix(toml): Remove underscore field support in 2024 (rust-lang/cargo#13804)
- fix: emit 1.77 syntax error only when msrv is incompatible (rust-lang/cargo#13808)
- docs(ref): Index differences between virtual / real manifests (rust-lang/cargo#13794)
- refactor(toml): extract dependency-to-source-id to function (rust-lang/cargo#13802)
- Add where lint was set (rust-lang/cargo#13801)
- fix(toml): Don't double-warn when underscore is used in workspace dep (rust-lang/cargo#13800)
- fix(toml): Be more forceful with underscore/dash redundancy (rust-lang/cargo#13798)
- Fix warning suppression for config.toml vs config compat symlinks (rust-lang/cargo#13793)
- Cleanup linting system (rust-lang/cargo#13797)

r? ghost
@rustbot rustbot added this to the 1.79.0 milestone Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation 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.

4 participants