Fallback to selecting installable candidates if possible when materializing specs #6225
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 or developer problem that led to this PR?
When running in legacy lockfile mode (only RUBY platform locked in Gemfile.lock), it may happen that we select a platform specific version, only to later find that it's not installable because of not matching ruby version requirements.
This is the case when having
nokogiri-1.3.10
in this kind of lockfile. This version ofnokogiri
only supports Ruby 3.2 in its generic version (though a "Ruby >= 2.6" requirement), but there are no yet precompiled versions for Ruby 3.2, so those don't support Ruby 3.2 (they use a ">= 2.6, < 3.2.DEV" requirement).So when upgrading such a lockfile to Ruby 3.2, we would incorrectly select a precompiled version, and fail to materialize it.
What is your fix for the problem, implemented in this PR?
Check the above situation before-hand so that we can fallback to the generic version.
Closes #6221.
Make sure the following tasks are checked