-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Workspace exclude
doesn't work if nested under a member
path
#6745
Comments
As a workaround, in "inner" you can include an empty I definitely see some wonkiness with checking paths "starts_with". |
Yeah, that's the workaround I'm using for now; I can imagine situations where it will be painful to change the inner package, though. |
I just encountered this when creating a dummy crate inside my The crate is only ever meant to be compiled as WASM so I don't want to include it in the normal workspace. Fortunately I have control over the source code so I can use the workaround proposed by @ehuss for now. |
In my case the top-most
and I want to exclude
but I get failures that
I was expecting anything listed in exclude (whether its heardcoded or a glob) to be removed from the |
Any chances this bug can be resolved, or are there any workarounds? Currently running into this problem since I want to create a binary for testing, and put it under the directory for the library it tests. |
This commit removes some items from the root manifest's workspace members array, and adds `witx-cli` to the root `workspace.exclude` array. The motivation for this stems from a cargo bug described in rust-lang/cargo#6745: `workspace.exclude` does not work if it is nested under a `workspace.members` path. See WebAssembly/WASI#438 for the underlying change to the WASI submodule which reorganized the `witx-cli` crate, and WebAssembly/WASI#398 for the original PR introducing `witx-cli`. See [this comment](bytecodealliance#3025 (comment)) for more details about the compilation errors, and failed alternative approaches that necessitated this change. N.B. This is not a functional change, these crates are still implicitly workspace members as transitive dependencies, but this will allow us to side-step the aforementioned cargo bug. Co-Authored-By: Alex Crichton <[email protected]>
* wasi-common: update wasi submodule This updates the WASI submodule, pulling in changes to the witx crate, now that there is a 0.9.1 version including some bug fixes. See WebAssembly/WASI#434 for more information. * wiggle: update witx dependencies * publish: verify and vendor witx-cli * adjust root workspace members This commit removes some items from the root manifest's workspace members array, and adds `witx-cli` to the root `workspace.exclude` array. The motivation for this stems from a cargo bug described in rust-lang/cargo#6745: `workspace.exclude` does not work if it is nested under a `workspace.members` path. See WebAssembly/WASI#438 for the underlying change to the WASI submodule which reorganized the `witx-cli` crate, and WebAssembly/WASI#398 for the original PR introducing `witx-cli`. See [this comment](#3025 (comment)) for more details about the compilation errors, and failed alternative approaches that necessitated this change. N.B. This is not a functional change, these crates are still implicitly workspace members as transitive dependencies, but this will allow us to side-step the aforementioned cargo bug. Co-Authored-By: Alex Crichton <[email protected]> Co-authored-by: Alex Crichton <[email protected]>
This odd little commit is a workaround for a Cargo workspaces bug, described in rust-lang/cargo#6745; this workaround is described in a comment there[1]. When using this repository as a submodule, it becomes impossible to validate the definitions with the command below, if it contains a Cargo workspace: ``` cargo run --manifest-path=validate-witx/Cargo.toml ./compute-at-edge.witx ``` Moreover, we cannot always add the repo to the `exclude` array, for reasons explained in the attached Cargo issue. So, we'll introduce this empty workspace array, to avoid that issue for now. [1]: rust-lang/cargo#6745 (comment)
[This is yet resolved] I am going to close this. Further discussion could happen in #11405. If you think this is wrong please leave a comment. We could reopen it. Edit: I think it is better to leave it open. |
I guess you can use this workaround. |
I'd like to confirm that this is still an issue with the following: exclude = ["runtime/crates/scripting"]
members = ["runtime/crates/*"]
I've side-stepped this for now by expanding out the |
These don't really do anything due to a Cargo limitation (rust-lang/cargo#6745).
These don't really do anything due to a Cargo limitation (rust-lang/cargo#6745).
These don't really do anything due to a Cargo limitation (rust-lang/cargo#6745).
Still facing this issue. It's particularly annoying when you have crates you'd like to exclude in a member's tests folder. |
#14155 contains an same test for cargo's testsuite. |
This works around rust-lang/cargo#6745 and allows cubeb-coreaudio-rs to appear as a subdirectory of a workspace member in another project (for instance, cubeb-rs).
This works around rust-lang/cargo#6745 and allows cubeb-pulse-rs to appear as a subdirectory of a workspace member in another project (for instance, cubeb-rs).
Once rust-lang/cargo#6745 is fixed, this `exclude` section will work and do what we need, but for now it is a no-op.
This works around rust-lang/cargo#6745 and allows cubeb-pulse-rs to appear as a subdirectory of a workspace member in another project (for instance, cubeb-rs).
This works around rust-lang/cargo#6745 and allows cubeb-coreaudio-rs to appear as a subdirectory of a workspace member in another project (for instance, cubeb-rs).
Once rust-lang/cargo#6745 is fixed, this `exclude` section will work and do what we need, but for now it is a no-op.
Once rust-lang/cargo#6745 is fixed, this `exclude` section will work and do what we need, but for now it is a no-op.
Once rust-lang/cargo#6745 is fixed, this `exclude` section will work and do what we need, but for now it is a no-op.
Problem
It doesn't appear as though the
workspace.exclude
key works for paths that are nested under a path included inworkspace.members
Steps
workspace.members
key to the outermost level, and observe that the workspace build succeeds:It still wants to be in the workspace! We're stuck.
Possible Solution(s)
If there's overlap between paths in
members
andexclude
, I would expect the more-specific path to win. In this case, the excluded path"middle/inner"
is more specific than the member paths"."
or"middle"
, so the exclusion should win. This is probably not so simple if the paths contain globs, though.Notes
Output of
cargo version
:Thanks for your looking into this 🦀
The text was updated successfully, but these errors were encountered: