Add a workspace.exclude key #3837
Conversation
This commit adds a new key to the `Cargo.toml` manifest, `workspace.exclude`. This new key is a list of strings which is an array of directories that are excluded from the workspace explicitly. This is intended for use cases such as vendoring where path dependencies into a vendored directory don't want to pull in the workspace dependencies. There's a number of use cases mentioned on rust-lang#3192 which I believe should all be covered with this strategy. At a bare minimum it should suffice to `exclude` every directory and then just explicitly whitelist crates through `members` through inclusion, and that should give precise control over the structure of a workspace. Closes rust-lang#3192
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
| Root { members: Option<Vec<String>> }, | ||
| Root { | ||
| members: Option<Vec<String>>, | ||
| exclude: Vec<String>, |
There was a problem hiding this comment.
Perhaps we should check that exclude is a relative path, to be conservative? Absolute paths probably do not make sense in this context.
There was a problem hiding this comment.
We could yeah, but we don't have checks like that for members and other such keys. I could imagine that in debugging situations it's useful to have absolute paths (although certainly never committed)
|
Implementation looks good to me, although I would probably try to use I wonder if we want to handle vendoring scenario automatically? That is, add directories of the replacement sources to |
|
@bors r+ |
|
📌 Commit 67364ba has been approved by |
Add a workspace.exclude key This commit adds a new key to the `Cargo.toml` manifest, `workspace.exclude`. This new key is a list of strings which is an array of directories that are excluded from the workspace explicitly. This is intended for use cases such as vendoring where path dependencies into a vendored directory don't want to pull in the workspace dependencies. There's a number of use cases mentioned on #3192 which I believe should all be covered with this strategy. At a bare minimum it should suffice to `exclude` every directory and then just explicitly whitelist crates through `members` through inclusion, and that should give precise control over the structure of a workspace. Closes #3192
|
☀️ Test successful - status-appveyor, status-travis |
|
@matklad oh I'm fine either way with I think it's ok though to avoid the vendoring scenario. It would only arise if you had a |
I've hit this when I've tried opening a vendored dependencies as a separate project in IntelliJ, because executing But this is a rather obscure edge case. If you open the main project in IntelliJ, poking vendored deps works just fine. |
|
Hm ok, if it becomes a problem then I think we can definitely update this to take vendoring into account, lemmek now if that becomes necessary! |
This commit adds a new key to the
Cargo.tomlmanifest,workspace.exclude.This new key is a list of strings which is an array of directories that are
excluded from the workspace explicitly. This is intended for use cases such as
vendoring where path dependencies into a vendored directory don't want to pull
in the workspace dependencies.
There's a number of use cases mentioned on #3192 which I believe should all be
covered with this strategy. At a bare minimum it should suffice to
excludeevery directory and then just explicitly whitelist crates through
membersthrough inclusion, and that should give precise control over the structure of a
workspace.
Closes #3192