You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: #5418
(for my use case then #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
0 commit comments