Workspaces: Add a way to disable transitive inclusion of path dependencies

[phil-opp]

Right now, a workspace root automatically includes all of its path dependencies as workspace members. It would be nice if we could disable this somehow.

This is a follow-up to #3156.

Use case:

Assume that we have a local library crate that we don't want to publish (yet). We include it in multiple executable crates through path = "../our_library" dependencies:

├── our_library
│   ├── Cargo.toml
│   └── src
├── executable_1
│   ├── Cargo.toml
│   └── src
└── executable_2
    ├── Cargo.toml
    └── src

Now we want to make the executables workspace roots. This leads to the following errors:

error: workspace member /home/…/our_library/Cargo.toml is not hierarchically below the workspace root /home/…/executable_{1,2}/Cargo.toml

So each executable requires that we make our_library a workspace member of its own workspace. But a crate can't be part of multiple workspaces.

Right now, there is no way to resolve this problem, since there is no way to disable the automatic inclusion of path dependencies.

[alexcrichton]

Thanks for the report!

[Boscop]

Upvote!
I run into this problem frequently.
The easiest solution would be to only make those imported crates that are in a subfolder of the workspace members of that workspace.
Especially if the workspace members are explicitly specified, there should be no confusion!
Anyone would intuitively assume that a workspace can only include crates in the subfolders.

[whitequark]

This makes using cargo workspaces a nightmare when I need to develop a crate outside of the workspace. Currently, for any trivial change, I have to:

• do a commit in the external crate
• get its git hash
• update Cargo.toml of the crate inside the workspace
• rebuild
• not forget to remove the dummy commits before pushing

[SergioBenitez]

Chiming in as I've run into this as well.

I believe the correct thing to do here is to assume that any path dependency that is not hierarchically below the workspace is not part of that workspace. In other words, do not implicitly include path dependencies that are not hierarchically below the workspace as members of that workspace. If a user explicitly adds such a member to the workspace, then this error can be given.

Edit: Ah, looks like #3443 implements exactly this.