Reactivate usused code for ruby version resolution

[larskanis]

The code was changed in commit 38b0e7e so that RubyVersion.system was no longer respected. This is reactivated now and specs are adjusted accordingly.

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

Not known.

What was your diagnosis of the problem?

I read the bundler source code and noticed this.

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

My fix re-adds the ruby version as it was before commit 38b0e7e , since it seems to be a mistake.

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

As a alternative I added #7558 that removes the code in question.

[deivid-rodriguez]

Thanks @larskanis! Do you have any particular preference? Intuitively to me, less code is better than more code, so I would go with #7558. @kou any opinion?

[kou]

I like #7558 too if we don't have regression by 38b0e7e. (I don't confirm it yet. Sorry.)

But I want to rename concat_ruby_version_requirements in #7558. Because it doesn't concat anything.

[larskanis]

I honesty don't really understand the impact of this code and I didn't find a difference in resolution between #7558 and #7559. But there's at least a user visible difference. In case of ruby version conflicts with #7522 this PR prints:

$ ruby -Ilib exe/bundle install
Fetching gem metadata from https://rubygems.org/............
Resolving dependencies...
Bundler found conflicting requirements for the Ruby  version:
  In Gemfile:
    Ruby  (= 2.7.0.0) x64-mingw32

    ffi (~> 1.11) x64-mingw32 was resolved to 1.11.3, which depends on
      Ruby  (>= 2.0)

while #7558 doesn't print the current ruby version:

$ ruby -Ilib exe/bundle install
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...
Bundler found conflicting requirements for the Ruby  version:
  In Gemfile:
    Ruby  x64-mingw32

    ffi (~> 1.11) x64-mingw32 was resolved to 1.11.3, which depends on
      Ruby  (>= 2.0)

This difference is why I had to adjust the specs in this PR.

[kou]

OK. I'll check this with #7522.

[deivid-rodriguez]

Mmm, I see. In that case, it sounds like this PR would be the way to go. At least I prefer the extra bit of clarification in the failure message.

[deivid-rodriguez]

@larskanis Can you rebase this PR?

[larskanis]

@deivid-rodriguez I rebased this PR and #7558 to master.

[deivid-rodriguez]

I'm going to go with this PR out of the two, let me know if any of you have any concerns.

@bundlerbot merge

[ghost]

Build succeeded

• continuous-integration/travis-ci/push
• windows (2.4.x)
• windows (2.5.x)
• windows (2.6.x)