Skip to content

For member under [workspace], Glob pattern doesn’t work for paths whose parent is excluded #11362

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

Open
Tracked by #11405
rinarakaki opened this issue Nov 11, 2022 · 6 comments
Labels
A-workspaces Area: workspaces C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@rinarakaki
Copy link

rinarakaki commented Nov 11, 2022

Problem

I want to group my related packages managed in the same repository under a directory, for example, libs/group-1 which you can think of as a sub-workspace but not a crate itself (there’s no Cargo.toml for it):


(Project Root)
├── Cargo.toml ([workspace])
├── libs
│   ├── group-1
│   │   ├── lib-1
│   │   │   └── Cargo.toml
│   │   └── lib-2
│   │       └── Cargo.toml
│   ├── lib-3
│   …
│   └── lib-n
…

I want to exclude only the path to it lib/group-1 from members — so Cargo won’t try to find its non-existent Cargo.toml based on the rule libs/* — but still include everything under the directory (libs/group-1/*), hence:

[workspace]
member = [
    "libs/*",
    "libs/group-1/*",
    "libs/group-1/lib-1"  # [1]
]
exclude = [
    "libs/group-1"
]

The problem is this doesn’t work, for example, for lib-2 located at libs/group-1/lib-2.

[1] Here I have added libs/group-1/lib-1 to explain where the intuition comes from, because this config is still valid and does work forlib-1.

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

No response

@rinarakaki rinarakaki added the C-bug Category: bug label Nov 11, 2022
@rinarakaki rinarakaki changed the title For member under [workspace], Glob pattern doesn’t work for paths whose parent is excludeed For member under [workspace], Glob pattern doesn’t work for paths whose parent is excluded Nov 11, 2022
@weihanglo
Copy link
Member

I had a hard time understanding what you want. Could you provide an example project and clarify what you want to include?

I also forgot the best way to show all workspace members. Maybe this?

cargo tree --workspace --depth 0 -e normal

@weihanglo weihanglo added the S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. label Nov 11, 2022
@rinarakaki
Copy link
Author

@weihanglo Thank you for your comment! I have added an example repository tree

@weihanglo
Copy link
Member

I see. Thanks for the explanation!

I believe this exclude rule is by design. workspace.exclude. From the chapter Workspaces in The Cargo Book:

The exclude key can be used to prevent paths from being included in a workspace. This can be useful if some path dependencies aren't desired to be in the workspace at all, or using a glob pattern and you want to remove a directory.

The contradictory happens between

  • Cargo understands members libs/* as every subdirectory under libs would be included as a member.
  • Cargo understands exclude libs/group-1 as removing the directory during probing members. That is, it won't include any path starting from lib/group-1 unless you explicitly set them in members. The code attributing this behaviour resides here.

Cargo aggressively probes Cargo.toml when you use a glob pattern. That is unlucky for your case. #4593 has more discussion and ideas to make Cargo smarter. Ideas around switching to .gitignore pattern also exist (#6009 (comment)). Before any of them proceeding, , reorganizing your project layout is the only suggestion I can give at this moment 😞.

I think both of the issues above cover what you try to resolve. I'd like to close this issue in favor of them. Does this sound good to you?

@weihanglo weihanglo added A-workspaces Area: workspaces and removed S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. labels Nov 11, 2022
@epage
Copy link
Contributor

epage commented Nov 11, 2022

I wish we could just use gitignores for members which would allow both including and excluding on a single field with a very obvious way for them to interact.

@ehuss
Copy link
Contributor

ehuss commented Nov 12, 2022

I also forgot the best way to show all workspace members. Maybe this?

cargo metadata | jq .workspace_members is usually the best way.

@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
@epage epage added the S-triage Status: This issue is waiting on initial triage. label Nov 20, 2024
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

4 participants