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

Workspace exclude doesn't work if nested under a member path #6745

Open
Tracked by #11405
acfoltzer opened this issue Mar 13, 2019 · 10 comments
Open
Tracked by #11405

Workspace exclude doesn't work if nested under a member path #6745

acfoltzer opened this issue Mar 13, 2019 · 10 comments
Labels
A-workspaces Area: workspaces C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@acfoltzer
Copy link

Problem

It doesn't appear as though the workspace.exclude key works for paths that are nested under a path included in workspace.members

Steps

  1. Create a nested package structure:
/tmp % cargo new outer
     Created binary (application) `outer` package
/tmp % cd outer
/tmp/outer % cargo new middle      
     Created binary (application) `middle` package
/tmp/outer % cd middle
/tmp/outer/middle % cargo new inner
     Created binary (application) `inner` package
  1. Add a workspace.members key to the outermost level, and observe that the workspace build succeeds:
/tmp/outer/middle % cd /tmp/outer
/tmp/outer % echo "[workspace]\n  members = [\".\", \"middle\"]" >> Cargo.toml
/tmp/outer % cargo build --all
   Compiling middle v0.1.0 (/tmp/outer/middle)                                                                                                                                                                                                                                            
   Compiling outer v0.1.0 (/tmp/outer)                                                                                                                                                                                                                                                    
    Finished dev [unoptimized + debuginfo] target(s) in 0.34s
  1. Now go to the inner package and observe that the build fails:
/tmp/outer % cd /tmp/outer/middle/inner 
/tmp/outer/middle/inner % cargo build
error: current package believes it's in a workspace when it's not:
current:   /tmp/outer/middle/inner/Cargo.toml
workspace: /tmp/outer/Cargo.toml

this may be fixable by adding `middle/inner` to the `workspace.members` array of the manifest located at: /tmp/outer/Cargo.toml
  1. Fair enough; let's explicitly exclude this package instead, and try again:
/tmp/outer/middle/inner % cd /tmp/outer
/tmp/outer % echo "exclude = [\"middle/inner\"]" >> Cargo.toml
/tmp/outer % cd /tmp/outer/middle/inner
/tmp/outer/middle/inner % cargo build
error: current package believes it's in a workspace when it's not:
current:   /tmp/outer/middle/inner/Cargo.toml
workspace: /tmp/outer/Cargo.toml

this may be fixable by adding `middle/inner` to the `workspace.members` array of the manifest located at: /tmp/outer/Cargo.toml

It still wants to be in the workspace! We're stuck.

Possible Solution(s)

If there's overlap between paths in members and exclude, 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:

% cargo version
cargo 1.31.0 (339d9f9c8 2018-11-16)

Thanks for your looking into this 🦀

@acfoltzer acfoltzer added the C-bug Category: bug label Mar 13, 2019
@ehuss
Copy link
Contributor

ehuss commented Mar 14, 2019

As a workaround, in "inner" you can include an empty [workspace] table, and it will work.

I definitely see some wonkiness with checking paths "starts_with".

@acfoltzer
Copy link
Author

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.

@Michael-F-Bryan
Copy link

I just encountered this when creating a dummy crate inside my examples/ directory and originally thought it had something to do with #6009.

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.

@felipesere
Copy link
Contributor

In my case the top-most Cargo.toml has:

[workspace]
members = [".", "crates/*", "commands/*"]
default-members = [".", "crates/*", "commands/*"]

and I want to exclude crates/README.md and commands/README.md with

exclude = ["crates/README.md", "commands/README.md"]

but I get failures that

$ cargo build                                                                                                                                        
error: failed to read `/Users/felipesere/Development/rust/orogene/crates/README.md/Cargo.toml`

Caused by:
  Not a directory (os error 20)

I was expecting anything listed in exclude (whether its heardcoded or a glob) to be removed from the members

@iitalics
Copy link

iitalics commented Aug 4, 2020

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.

cratelyn pushed a commit to cratelyn/wasmtime that referenced this issue Jun 24, 2021
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]>
alexcrichton added a commit to bytecodealliance/wasmtime that referenced this issue Jun 24, 2021
* 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]>
cratelyn pushed a commit to fastly/compute-at-edge-abi that referenced this issue Jul 7, 2021
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)
@weihanglo
Copy link
Member

weihanglo commented Nov 22, 2022

[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.

@weihanglo weihanglo closed this as not planned Won't fix, can't repro, duplicate, stale Nov 22, 2022
@weihanglo weihanglo reopened this Nov 22, 2022
@Rustin170506
Copy link
Member

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.

I guess you can use this workaround.

@philpax
Copy link
Contributor

philpax commented Jan 27, 2023

I'd like to confirm that this is still an issue with the following:

exclude = ["runtime/crates/scripting"]
members = ["runtime/crates/*"]

scripting does not contain a Cargo.toml (it holds other crates), so this causes an error:

error: failed to load manifest for workspace member `runtime\crates\scripting`

Caused by:
  failed to read `runtime\crates\scripting\Cargo.toml`

Caused by:
  The system cannot find the file specified. (os error 2)

I've side-stepped this for now by expanding out the crates/* glob manually, but it would be nice to have more predictable behaviour here.

Kobzol added a commit to Kobzol/rustc-perf that referenced this issue Jun 23, 2023
These don't really do anything due to a Cargo limitation (rust-lang/cargo#6745).
Kobzol added a commit to Kobzol/rustc-perf that referenced this issue Jun 23, 2023
These don't really do anything due to a Cargo limitation (rust-lang/cargo#6745).
Kobzol added a commit to Kobzol/rustc-perf that referenced this issue Jun 23, 2023
These don't really do anything due to a Cargo limitation (rust-lang/cargo#6745).
@epage epage added the S-triage Status: This issue is waiting on initial triage. label Oct 31, 2023
@warfaj
Copy link

warfaj commented Jan 7, 2024

Still facing this issue. It's particularly annoying when you have crates you'd like to exclude in a member's tests folder.

@ehuss
Copy link
Contributor

ehuss commented Jun 26, 2024

#14155 contains an same test for cargo's testsuite.

mutexlox-signal added a commit to mutexlox-signal/cubeb-coreaudio-rs that referenced this issue Sep 26, 2024
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).
mutexlox-signal added a commit to mutexlox-signal/cubeb-pulse-rs that referenced this issue Sep 26, 2024
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).
mutexlox-signal added a commit to mutexlox-signal/cubeb-rs that referenced this issue Sep 26, 2024
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.
kinetiknz pushed a commit to mozilla/cubeb-pulse-rs that referenced this issue Oct 10, 2024
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).
kinetiknz pushed a commit to mozilla/cubeb-coreaudio-rs that referenced this issue Oct 10, 2024
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).
mutexlox-signal added a commit to mutexlox-signal/cubeb-rs that referenced this issue Oct 16, 2024
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.
mutexlox-signal added a commit to mutexlox-signal/cubeb-rs that referenced this issue Oct 16, 2024
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.
padenot pushed a commit to mozilla/cubeb-rs that referenced this issue Oct 17, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-workspaces Area: workspaces C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

10 participants