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
Do not consider platform gems as candidates when required_ruby_version
is incompatible
#5715
Labels
Comments
Right, yeah. I'll fix this. |
Some prior context on related/same issue: #4012 |
Yes, I believe they are very similar issues but in that case it was a "resolution from scratch" issue, while in this case it's a "lockfile issue". |
This was referenced Jul 25, 2022
#5784 should fix this! |
@deivid-rodriguez thank you so much! when do you think this patch will make it in a release? |
No problem, next week! |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the problem as clearly as you can
When selecting a spec to use when a platform spec is available, currently Bundler will choose the platform matching gem even when it is not compatible with the
required_ruby_version
.The consequences of this means that it's impossible to publish precompiled gems that fallback to compiling from source code on newer Ruby versions. At Shopify, this makes it so we have to use a bunch of hacks to test gems against
ruby-head
.Here's a more concrete example of the issue:
In the above test, Bundler should choose
my-precompiled-gem (3.0.0)
. Today, it will pickmy-precompiled-gem (3.0.0-#{Bundler.local_platform})
and simply raise an error inensure_specs_are_compatible!
.cc: @flavorjones
The text was updated successfully, but these errors were encountered: