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
Ad-hoc fix for platform regression #4127
Conversation
f27df1e
to
2cfbe9d
Compare
fea47ce
to
614e13f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Unfortunately all regressions in 2.2.0 have been caused by #4015, so I'm considering full revert of that as an alternative to this PR, since I don't currently have a solution for #4128. So let me investigate a bit more this weekend and we can release patch level versions on Monday with either approach. Does that sound good? |
ac6efa2
to
467c43a
Compare
467c43a
to
2a18ec7
Compare
We should be able to remove this once we have proper bundler version switching.
2a18ec7
to
6ebb0e3
Compare
Ad-hoc fix for platform regression (cherry picked from commit 6a8791c)
2.2.1 has a fix for some platform specific stuff which seems worth adopting ASAP: rubygems/rubygems#4127
What was the end-user or developer problem that led to this PR?
In bundler 2.2 we switched to a "strict platform materialization". That means that the exact resolution, including the platform specific gems resolved for each specific platform, and the specific platforms themselves are now recorded in the lockfile.
Previously, the resolution was done without considering platform specific variants at all, and then at install time, a platform specific version for the resolved version would be installed if it happens to exist.
With the fixed behaviour though, if we are materializing a lock file created with an old bundler version, the new bundler version will interpret that the pure ruby version was resolved (since that's what it finds in the lock file) and try to materialize that. However, that version doesn't really exist in the system (it's the platform specific variant that got installed).
This change should restore backwards compatibility in this regard.
What is your fix for the problem, implemented in this PR?
My fix is to check the version of bundler present in the lock file (if it exists), which indicates the version of bundler that created it. If that version is prior to 2.2.0, we fallback to the old behaviour.
We should be able to remove this once we have proper bundler version switching.
Fixes #4123.
Fixes #4122 too, I think.
Make sure the following tasks are checked