Skip to content

workspace.default-members should allow "." in non-virtual workspaces #10783

Closed
@tedinski

Description

@tedinski

Problem

The workspace.members list implicitly includes the root package. But if one tries to put "." in default-members, you get the error:

error: package `/some/path/.` is listed in workspace’s default-members but is not a member.

The complicating problem is that when you put "." into workspace.members, you run into #6745 in the worst way. Putting "." there means workspace.exclude fails to work entirely due to that bug.

I think the default-members check is being overly restrictive here, and should allow "." in non-virtual workspaces without requiring it to appear in members explicitly. This would at least enable a workaround for this problem until the other bug is fixed.

Steps

./Cargo.toml    (Package and workspace)
./src/          (Root is a package, not virtual, so this exists)
./included/     (Package to include in workspace)
./nondefault/   (Package that should be included, but not a default-member)
./excluded/     (Package that should be excluded from the workspace)

with

[workspace]
members = ["included", "nondefault"]
default-members = [".", "included"]
exclude = ["excluded"]

Expected: cargo build builds the root package and included.
Actual: cargo rejects this config because "." is not in members.

If we add "." to members, then the above works, but:
Expected: cargo build in the excluded package would build independently from the workspace.
Actual:

error: current package believes it's in a workspace when it's not:
current:   /some/path/excluded/Cargo.toml
workspace: /some/path/Cargo.toml

this may be fixable by adding `excluded` to the `workspace.members` array of the manifest located at: /some/path/Cargo.toml

This is bug #6745 telling me to add excluded to exclude to fix the problem, but of course it already is.

Possible Solution(s)

I can't find any workaround that works for me. It seems adding a blank [workspace] to excluded's Cargo.toml will fix the issue for single package, but I've got a whole test suite of packages I didn't want to update them all.

I believe a reasonable fix might be as simple as relaxing this check in cargo.

Notes

No response

Version

cargo 1.63.0-nightly (85e457e15 2022-06-07)
release: 1.63.0-nightly
commit-hash: 85e457e158db216a2938d51bc3b617a5a7fe6015
commit-date: 2022-06-07
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1n)
os: Ubuntu 20.04 (focal) [64-bit]

cargo 1.61.0 (a028ae4 2022-04-29)
release: 1.61.0
commit-hash: a028ae42fc1376571de836be702e840ca8e060c2
commit-date: 2022-04-29
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: Ubuntu 20.04 (focal) [64-bit]

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions