Add more suggestions on how to deal with excluding a package from a workspace. #6805
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @Eh2406 (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors: r+ |
|
📌 Commit d7a9212 has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Apr 1, 2019
Add more suggestions on how to deal with excluding a package from a workspace. Closes #5418
|
☀️ Test successful - checks-travis, status-appveyor |
Centril
added a commit
to Centril/rust
that referenced
this pull request
Apr 5, 2019
Update cargo 20 commits in 63231f438a2b5b84ccf319a5de22343ee0316323..6f3e9c367abb497c64f360c3839dab5e74928d5c 2019-03-27 12:26:45 +0000 to 2019-04-04 14:11:33 +0000 - Fix Init for Fossil SCM project (rust-lang/cargo#6792) - Fix member_manifest_version_error accessing the network (rust-lang/cargo#6799) - Don't include email if it is empty (rust-lang/cargo#6802) - Fix unused import warning (rust-lang/cargo#6807) - Add some help and documentation for unstable flags (rust-lang/cargo#6791) - Allow `cargo doc --open` with multiple packages (rust-lang/cargo#6803) - Allow `cargo install --path P` to load config from P (rust-lang/cargo#6804) - Add more suggestions on how to deal with excluding a package from a workspace (rust-lang/cargo#6805) - Warn on version req with metadata (rust-lang/cargo#6806) - cargo install: Be more restrictive about cli flags (rust-lang/cargo#6801) - Support force-pushed repos with git-fetch-with-cli (rust-lang/cargo#6800) - Cargo clippy (rust-lang/cargo#6759) - Don't include metadata in wasm binary examples (rust-lang/cargo#6812) - Update glossary for `feature` (rust-lang/cargo#6809) - Include proc-macros in `build-override` (rust-lang/cargo#6811) - Resolver: A dep is equivalent to one of the things it can resolve to (rust-lang/cargo#6776) - Add some docs for `Downloads` (rust-lang/cargo#6815) - Resolve: Be less strict while offline (rust-lang/cargo#6814) - Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818) - Fix doc link (rust-lang/cargo#6820) <br> I specifically care about "Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)" to unblock rust-lang#59076. Mentioning @ehuss.
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Apr 5, 2019
Update cargo 20 commits in 63231f438a2b5b84ccf319a5de22343ee0316323..6f3e9c367abb497c64f360c3839dab5e74928d5c 2019-03-27 12:26:45 +0000 to 2019-04-04 14:11:33 +0000 - Fix Init for Fossil SCM project (rust-lang/cargo#6792) - Fix member_manifest_version_error accessing the network (rust-lang/cargo#6799) - Don't include email if it is empty (rust-lang/cargo#6802) - Fix unused import warning (rust-lang/cargo#6807) - Add some help and documentation for unstable flags (rust-lang/cargo#6791) - Allow `cargo doc --open` with multiple packages (rust-lang/cargo#6803) - Allow `cargo install --path P` to load config from P (rust-lang/cargo#6804) - Add more suggestions on how to deal with excluding a package from a workspace (rust-lang/cargo#6805) - Warn on version req with metadata (rust-lang/cargo#6806) - cargo install: Be more restrictive about cli flags (rust-lang/cargo#6801) - Support force-pushed repos with git-fetch-with-cli (rust-lang/cargo#6800) - Cargo clippy (rust-lang/cargo#6759) - Don't include metadata in wasm binary examples (rust-lang/cargo#6812) - Update glossary for `feature` (rust-lang/cargo#6809) - Include proc-macros in `build-override` (rust-lang/cargo#6811) - Resolver: A dep is equivalent to one of the things it can resolve to (rust-lang/cargo#6776) - Add some docs for `Downloads` (rust-lang/cargo#6815) - Resolve: Be less strict while offline (rust-lang/cargo#6814) - Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818) - Fix doc link (rust-lang/cargo#6820) <br> I specifically care about "Accept trailing comma in test of impl Debug for PackageId (rust-lang/cargo#6818)" to unblock #59076. Mentioning @ehuss.
rib
added a commit
to rib/cargo
that referenced
this pull request
Jun 2, 2025
If a root directory is specified then cargo will only search ancestors looking for `.cargo` config files and workspaces up until the root directory is reached (instead of walking to the root of the filesystem). A root can be specified in three ways: 1. The existence of a `.cargo/root` file (discovered by checking parents up towards the root of the filesystem) 2. By setting the `CARGO_ROOT` environment variable 3. By passing `--root` on the command line If more than one is specified then the effective root is the one that's most-specific / closest to the current working directory. ### What does this PR try to resolve? Fixes: rust-lang#5418 (for my use case then rust-lang#6805 isn't a practical workaround) This goes some way to allow nesting of workspaces, by adding a way to limit the directories that Cargo searches when looking for config files and workspace manifests. This does not enable nesting in the form of workspace inheritance - but does provide the means to technically have a filesystem with nested workspaces (that aren't aware of each other) and be able to hide any outer (unrelated) workspace while building a nested workspace. This gives more flexibility for tools that want to use cargo as an implementation detail. In particular this allows you to sandbox the build of nested third-party workspaces that may be (unknowingly) dynamically unpacked within an outer workspace, in situations where neither the workspace being built and the outer workspace are owned by the tool that is managing the build. For example a tool based on rustdoc-json should be able to fetch and build documentation for third-party crates under any user-specified build/target directory without having to worry about spooky action at a distance due to config files and workspaces in ancestor directories. In my case, I have a runtime for coding with LLMs that is given a repo to work on and is expected to keep its artifacts contained to a `.ai/` directory. This runtime supports building markdown documentation for Rust crates, which involves using cargo to generate rustdoc-json data. That tool is expected to keep its artifacts contained within `.ai/docs/rust/build/`. It's possible that the project itself is Rust based and could define a workspace or `.cargo/config.toml` but from the pov of this toolchain those have nothing to do with the crate whose documentation is being generated (which are packages downloaded from crates.io). ### How to test and review this PR? TODO: write tests
rib
added a commit
to rib/cargo
that referenced
this pull request
Jun 2, 2025
If a root directory is specified then cargo will only search ancestors looking for `.cargo` config files and workspaces up until the root directory is reached (instead of walking to the root of the filesystem). A root can be specified in three ways: 1. The existence of a `.cargo/root` file (discovered by checking parents up towards the root of the filesystem) 2. By setting the `CARGO_ROOT` environment variable 3. By passing `--root` on the command line If more than one is specified then the effective root is the one that's most-specific / closest to the current working directory. ### What does this PR try to resolve? Fixes: rust-lang#5418 (for my use case then rust-lang#6805 isn't a practical workaround) This goes some way to allow nesting of workspaces, by adding a way to limit the directories that Cargo searches when looking for config files and workspace manifests. This does not enable nesting in the form of workspace inheritance - but does provide the means to technically have a filesystem with nested workspaces (that aren't aware of each other) and be able to hide any outer (unrelated) workspace while building a nested workspace. This gives more flexibility for tools that want to use cargo as an implementation detail. In particular this allows you to sandbox the build of nested third-party workspaces that may be (unknowingly) dynamically unpacked within an outer workspace, in situations where neither the workspace being built and the outer workspace are owned by the tool that is managing the build. For example a tool based on rustdoc-json should be able to fetch and build documentation for third-party crates under any user-specified build/target directory without having to worry about spooky action at a distance due to config files and workspaces in ancestor directories. In my case, I have a runtime for coding with LLMs that is given a repo to work on and is expected to keep its artifacts contained to a `.ai/` directory. This runtime supports building markdown documentation for Rust crates, which involves using cargo to generate rustdoc-json data. That tool is expected to keep its artifacts contained within `.ai/docs/rust/build/`. It's possible that the project itself is Rust based and could define a workspace or `.cargo/config.toml` but from the pov of this toolchain those have nothing to do with the crate whose documentation is being generated (which are packages downloaded from crates.io). ### How to test and review this PR? TODO: write tests
rib
added a commit
to rib/cargo
that referenced
this pull request
Jun 2, 2025
If a root directory is specified then cargo will only search ancestors looking for `.cargo` config files and workspaces up until the root directory is reached (instead of walking to the root of the filesystem). A root can be specified in three ways: 1. The existence of a `.cargo/root` file (discovered by checking parents up towards the root of the filesystem) 2. By setting the `CARGO_ROOT` environment variable 3. By passing `--root` on the command line If more than one is specified then the effective root is the one that's most-specific / closest to the current working directory. ### What does this PR try to resolve? Fixes: rust-lang#5418 (for my use case then rust-lang#6805 isn't a practical workaround) This goes some way to allow nesting of workspaces, by adding a way to limit the directories that Cargo searches when looking for config files and workspace manifests. This does not enable nesting in the form of workspace inheritance - but does provide the means to technically have a filesystem with nested workspaces (that aren't aware of each other) and be able to hide any outer (unrelated) workspace while building a nested workspace. This gives more flexibility for tools that want to use cargo as an implementation detail. In particular this allows you to sandbox the build of nested third-party workspaces that may be (unknowingly) dynamically unpacked within an outer workspace, in situations where neither the workspace being built and the outer workspace are owned by the tool that is managing the build. For example a tool based on rustdoc-json should be able to fetch and build documentation for third-party crates under any user-specified build/target directory without having to worry about spooky action at a distance due to config files and workspaces in ancestor directories. In my case, I have a runtime for coding with LLMs that is given a repo to work on and is expected to keep its artifacts contained to a `.ai/` directory. This runtime supports building markdown documentation for Rust crates, which involves using cargo to generate rustdoc-json data. That tool is expected to keep its artifacts contained within `.ai/docs/rust/build/`. It's possible that the project itself is Rust based and could define a workspace or `.cargo/config.toml` but from the pov of this toolchain those have nothing to do with the crate whose documentation is being generated (which are packages downloaded from crates.io). ### How to test and review this PR? TODO: write tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #5418