You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Auto merge of rust-lang#3562 - matklad:member-workspace, r=alexcrichton
Find workspace via `workspace_root` link in containing member
This PR proposes to change the logic for determining workspace members. Here are the algorithms we used previously for this:
# [RFC](https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md) flavor
If `[members]` key present, it compliantly defines the set of members. Otherwise, members are all (transitive) path dependencies.
The problem with this approach is that it violates convention over configuration principle: almost always you want a path dependency to be a member, even if there are some explicit members. Listing **all** path deps is just to much work.
# Original implementation
So, the actual algorithm **unconditionally** included path dependencies as memebers.
This is also problematic, because certain workspace configurations become impossible. In particular, you can't have a path dependency which is not a member of the workspace. This issue was reported in rust-lang#3192.
# Current implementation
Current implementation (was merged couple of days ago) includes path dependency into the workspace only if is inside the workspace directory. This solves the problem in rust-lang#3192 perfectly. However, some configuration are still impossible: you can't have a non-member path dependency inside a workspace directory. But the thinking is that if you don't want this path-dep to be a member, just don't put it inside the workspace directory.
There is another problem with current imlementation. Suppose you have an explicit member which lives alongside the workspace. Suppose this member has a path-dep which lives inside the member's folder. Under current implementation, this path-dep won't be a member of the workspace. It seems logical that it should be though (but we haven't received any actual bug reports yet)!
# Implementation in this PR
So, with this PR, the logic is as follows: members are explicit members + all path dependencies which reside under any of the explicit members.
0 commit comments