Find workspace via workspace_root link in containing member
#3562
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
There's a subtlety to this implementation: |
|
Thanks for the PR @matklad! The implementation looks good to me. cc @rust-lang/tools, thoughts? |
|
Ok we talked about this during triage the other day and the @rust-lang/tools team was all comfortable with this. @matklad what do you think about holding off merging until after the next version is branched? That way we can maximize the time here in testing. |
|
Thanks @matklad ! |
|
@matklad hm perhaps yeah, but we can keep a close eye on it and revert if anything seems awry |
|
@bors: r+ Beta was branched! |
|
📌 Commit 3435414 has been approved by |
|
⌛ Testing commit 3435414 with merge 2a8c145... |
|
@bors: retry
|
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 #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 #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.
|
☀️ Test successful - status-appveyor, status-travis |
This PR proposes to change the logic for determining workspace members. Here are the algorithms we used previously for this:
RFC 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 #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 #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.