This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Consistent lockfiles #7264
Merged
Consistent lockfiles #7264
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
deivid-rodriguez
force-pushed
the
consistent_lockfiles
branch
from
7c7b557
to
2a50f33
Compare
When Gemfile would specify path sources as relative paths starting with "./", the lockfile would have inconsistent order on `bundle install` and `bundle update`.
deivid-rodriguez
force-pushed
the
consistent_lockfiles
branch
from
2a50f33
to
c7532ce
Compare
|
Not sure who to request a review from here, specially since @segiddins is usually very busy. If I don't get any reviews in a few days, I'll go ahead and merge, since this fixes a bug and includes a regression spec. @SolaWing Did you confirm that this fixes your issue, by the way? |
|
@deivid-rodriguez yes, I have patched the code and confirmed it |
|
@bundlerbot r+ |
ghost
pushed a commit
that referenced
this pull request
Aug 4, 2019
7264: Consistent lockfiles r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that when a Gemfile would specify path sources with paths starting with "./", the generated lockfile would be inconsistent on `bundle install` and `bundle update`.
### What was your diagnosis of the problem?
My diagnosis was that when running `bundle update`, the bundle would be unlocked, and bundler would order the path sources according to the path present in the Gemfile ("./aaa" for example). On the other hand, when running `bundle install`, bundler would read the relative paths from the lockfile, where they are normalized ("aaa" for example).
### What is your fix for the problem, implemented in this PR?
My fix is to normalize relative paths when creating the source list, so that "aaa" is always used over "./aaa".
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem and it's backwards compatible (as in, it doesn't break any specs that assert for specific lockfiles).
Fixes #7262.
Co-authored-by: David Rodríguez <[email protected]>
Build failed |
|
I really need to investigate this flaky... 😠 @bundlerbot retry |
ghost
pushed a commit
that referenced
this pull request
Aug 4, 2019
7264: Consistent lockfiles r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that when a Gemfile would specify path sources with paths starting with "./", the generated lockfile would be inconsistent on `bundle install` and `bundle update`.
### What was your diagnosis of the problem?
My diagnosis was that when running `bundle update`, the bundle would be unlocked, and bundler would order the path sources according to the path present in the Gemfile ("./aaa" for example). On the other hand, when running `bundle install`, bundler would read the relative paths from the lockfile, where they are normalized ("aaa" for example).
### What is your fix for the problem, implemented in this PR?
My fix is to normalize relative paths when creating the source list, so that "aaa" is always used over "./aaa".
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem and it's backwards compatible (as in, it doesn't break any specs that assert for specific lockfiles).
Fixes #7262.
Co-authored-by: David Rodríguez <[email protected]>
Build failed |
|
@bundlerbot retry |
|
@bundlerbot r+ |
ghost
pushed a commit
that referenced
this pull request
Aug 5, 2019
7264: Consistent lockfiles r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that when a Gemfile would specify path sources with paths starting with "./", the generated lockfile would be inconsistent on `bundle install` and `bundle update`.
### What was your diagnosis of the problem?
My diagnosis was that when running `bundle update`, the bundle would be unlocked, and bundler would order the path sources according to the path present in the Gemfile ("./aaa" for example). On the other hand, when running `bundle install`, bundler would read the relative paths from the lockfile, where they are normalized ("aaa" for example).
### What is your fix for the problem, implemented in this PR?
My fix is to normalize relative paths when creating the source list, so that "aaa" is always used over "./aaa".
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem and it's backwards compatible (as in, it doesn't break any specs that assert for specific lockfiles).
Fixes #7262.
Co-authored-by: David Rodríguez <[email protected]>
Build succeeded |
ghost
merged commit
This pull request was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was the end-user problem that led to this PR?
The problem was that when a Gemfile would specify path sources with paths starting with "./", the generated lockfile would be inconsistent on
bundle installandbundle update.What was your diagnosis of the problem?
My diagnosis was that when running
bundle update, the bundle would be unlocked, and bundler would order the path sources according to the path present in the Gemfile ("./aaa" for example). On the other hand, when runningbundle install, bundler would read the relative paths from the lockfile, where they are normalized ("aaa" for example).What is your fix for the problem, implemented in this PR?
My fix is to normalize relative paths when creating the source list, so that "aaa" is always used over "./aaa".
Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem and it's backwards compatible (as in, it doesn't break any specs that assert for specific lockfiles).
Fixes #7262.