Skip to content
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

Find workspace via workspace_root link in containing member #3562

Merged
merged 1 commit into from
Feb 2, 2017

Conversation

matklad
Copy link
Member

@matklad matklad commented Jan 19, 2017

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.

@rust-highfive
Copy link

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@matklad matklad mentioned this pull request Jan 19, 2017
@matklad
Copy link
Member Author

matklad commented Jan 19, 2017

There's a subtlety to this implementation: find_root function does not need an update, because this condition will fire.

@alexcrichton
Copy link
Member

Thanks for the PR @matklad! The implementation looks good to me.

cc @rust-lang/tools, thoughts?

@alexcrichton alexcrichton added the relnotes Release-note worthy label Jan 20, 2017
@alexcrichton
Copy link
Member

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.

@brson
Copy link
Contributor

brson commented Jan 27, 2017

Thanks @matklad !

@matklad
Copy link
Member Author

matklad commented Jan 28, 2017

@matklad what do you think about holding off merging until after the next version is branched?

Yes, that's prudent! Perhaps the same should have been done to #3443?

@alexcrichton
Copy link
Member

@matklad hm perhaps yeah, but we can keep a close eye on it and revert if anything seems awry

@alexcrichton
Copy link
Member

@bors: r+

Beta was branched!

@bors
Copy link
Contributor

bors commented Jan 31, 2017

📌 Commit 3435414 has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Feb 1, 2017

⌛ Testing commit 3435414 with merge 2a8c145...

@alexcrichton
Copy link
Member

@bors: retry

  • prioritizing a beta fix

@bors
Copy link
Contributor

bors commented Feb 2, 2017

⌛ Testing commit 3435414 with merge 0ee14de...

bors added a commit that referenced this pull request Feb 2, 2017
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.
@bors
Copy link
Contributor

bors commented Feb 2, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 0ee14de to master...

@bors bors merged commit 3435414 into rust-lang:master Feb 2, 2017
@matklad matklad deleted the member-workspace branch February 14, 2017 09:59
@ehuss ehuss added this to the 1.17.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Release-note worthy
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants