Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

[2.0] [Resolver] Error when it is ambigous which transitive source a gem should come from #5985

Merged
merged 1 commit into from Sep 10, 2017

Conversation

segiddins
Copy link
Member

What was the end-user problem that led to this PR?

The problem was the "source priority" in ambiguous source situations was ... ambiguous.

What was your diagnosis of the problem?

My diagnosis was we should error and require a user explicitly pin the dependency to a source in those situations, rather than leaving the source used up to an implementation detail.

What is your fix for the problem, implemented in this PR?

My fix attempts to implement the priority described in the conversation in #4629.

Why did you choose this fix out of the possible options?

I chose this fix because it still allows using the default source as a backup, while only taking the "relevant" sources into account, so that the error/warning is not overzealous.

@segiddins segiddins changed the title [Resolver] Error when it is ambigous which transitive source a gem should come from [2.0] [Resolver] Error when it is ambigous which transitive source a gem should come from Aug 30, 2017
@segiddins segiddins force-pushed the seg-multisource-error branch 2 times, most recently from 7588b8a to f096219 Compare August 30, 2017 22:08
@segiddins segiddins modified the milestones: 1.15.4, 2.0 — Breaking Changes Aug 31, 2017
@segiddins
Copy link
Member Author

@indirect r?

@indirect
Copy link
Member

This looks right to me! @bundlerbot r+

@bundlerbot
Copy link
Collaborator

📌 Commit 789974c has been approved by indirect

@bundlerbot
Copy link
Collaborator

⌛ Testing commit 789974c with merge 5df439c...

bundlerbot added a commit that referenced this pull request Sep 10, 2017
[2.0] [Resolver] Error when it is ambigous which transitive source a gem should come from

### What was the end-user problem that led to this PR?

The problem was the "source priority" in ambiguous source situations was ... ambiguous.

### What was your diagnosis of the problem?

My diagnosis was we should error and require a user explicitly pin the dependency to a source in those situations, rather than leaving the source used up to an implementation detail.

### What is your fix for the problem, implemented in this PR?

My fix attempts to implement the priority described in the conversation in #4629.

### Why did you choose this fix out of the possible options?

I chose this fix because it still allows using the default source as a backup, while only taking the "relevant" sources into account, so that the error/warning is not overzealous.
@bundlerbot
Copy link
Collaborator

☀️ Test successful - status-travis
Approved by: indirect
Pushing 5df439c to master...

@bundlerbot bundlerbot merged commit 789974c into master Sep 10, 2017
@hsbt hsbt deleted the seg-multisource-error branch December 22, 2017 05:37
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants