rails: Bundle Update Fails for Rails 6.1 if Ruby >= 2.6

NOTE: This is in reference to running bundle update in a checked out copy of Rails 6.1 (master). This does not apply to updating gems for an app that uses Rails 6.1

Applies to:

Current Rails 6.1 master
Any Ruby version >= 2.6.0
Tested on MacOS / Darwin (I assume all systems are affected)

Steps to Reproduce

Using any version of Ruby >= 2.6.0:

Check out a copy of Rails master
Run bundle install which will work
Run bundle update which will fail

git clone 'https://github.com/rails/rails/' ./tmprails
cd ./tmprails

# This will work OK
bundle install

# This will fail
bundle update

Expected Behavior

Bundler will update dependencies.

Actual Behavior

Bundler fails with:

Bundler could not find compatible versions for gem "ruby":
  In Gemfile:
    ruby

    mysql2 (~> 0.5) was resolved to 0.5.2, which depends on
      ruby (< 2.6) x64-mingw32

    mysql2 (~> 0.5) was resolved to 0.5.2, which depends on
      ruby (< 2.6) x86-mingw32

    nokogiri (>= 1.8.1) was resolved to 1.10.4, which depends on
      ruby (>= 2.3) x64-mingw32

    nokogiri (>= 1.8.1) was resolved to 1.10.4, which depends on
      ruby (>= 2.3) x86-mingw32

    rails was resolved to 6.1.0.alpha, which depends on
      ruby (>= 2.5.0)

Details. A problem with `mysql2` version `0.5`

This appears to have been introduced in https://github.com/rails/rails/pull/37191 where we bumped mysql2 to version 0.5. The Windows binaries for mysql2 versions >= 0.5 have a Ruby version requirement of < 2.6, >= 2.0 (e.g. https://rubygems.org/gems/mysql2/versions/0.5.0-x86-mingw32). This Ruby requirement is imposed on all platforms such that even non-windows systems can not update unless using ruby (< 2.6).

mysql2 versions earlier than 0.5 had a Ruby requirement of >= 0.

Related Background:

At GitHub, this is currently blocking us from testing with Rails 6.1. Our process for vendoring Rails began failing for our “Rails Next” update after the https://github.com/rails/rails/pull/37191 PR. This is because our process includes a bundle install step that happens in such a way as to cause dependencies on all platforms to be re-checked in the same way that bundle update does.

As a side note: I’m not entirely sure whether this is a Rails issue, a MySQL2 issue, or a bundler issue. I’m opening this as a first step to figuring that out.

CC: @kamipo as author of the PR mentioned above, @eileencodes for visibility

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 15 (13 by maintainers)

Most upvoted comments

@sodabrew unfortunately does not have time to upgrade the mysql2 plug-in. We are waiting now almost a year for it. Could Rails developers team pick this up? The plug-in actually important for Rails 6 and mysql compatibility. Many people are using mysql. It is actually baffling why such plugins are actually not part of Rails. Rails require databases to run. Mysql2 plug-in is actually dragging Rails back. The old plug-in also have problem with Mysql 8.0 “Mysql2::Error: Authentication", now days security is important with all new CVS and no one stays on top of it, as for example @sodabrew does not have time. Please think about it.

ghost on Sep 24, 2019

Another quick followup for the sake of completeness: I don’t think this is related to the bundler issues above. I think this is actually a mysql2 issue. The problem exists with bundler 1.17.3 so bundler’s “auto multiplatform” isn’t a factor since it’s only a bundler 2 change. On the other hand, there’s an open issue with mysql2 regarding Ruby 2.6 support:

https://github.com/brianmario/mysql2/issues/1021

As far as I can tell, our Gemfile.lock includes the x64-mingw32 and x86-mingw32 platforms which are enforced during bundle update and the mysql2 max ruby version requirement fails when running Ruby >= 2.6.

cpruitt on Sep 24, 2019

rubygems/bundler#6247 has been fixed by rubygems/bundler#7522. Bundler 2.2.0 will fix this.

kou on Mar 9, 2020

Hey, no, I think this remains an open issue, regardless of whether I’m timely in releasing new Windows builds of mysql2. The Windows Ruby dev toolkits traditionally have lagged months behind the Dec 25 new Ruby releases. Maybe in recent years that’s improved, but it still demands annual action on Dec 25 on my part. I suggest to focus on the underlying problem here:

This Ruby requirement is imposed on all platforms such that even non-windows systems can not update unless using ruby (< 2.6).

If I have a gem with a binary build for some platforms, that binary build will only be available for the Ruby platforms that were known at build time. Imposing the version requirement to other platforms doesn’t make sense to me. I would solve this problem by halting Windows builds and telling Windows users that they’re on their own to figure out how to compile the gem, right? So that way I’m only distributing the ruby architecture variant. If that’s what it takes, but that’d be sad. About five year sago, I spent over a year deeply figuring this out for myself and getting working builds for Windows for mysql2 and eventmachine, and that’s on top of the incredible work of folks like @kou, @larskanis, @MSP-Greg creating Rake Compiler and Ruby Installer. But maybe the build-at-installation capability for Windows is commonplace now? Traditionally Windows systems do not have compilers widely available.

I propose as an acid test: if I get a request on December 25 that I’ve broken mysql2 installation for Ruby 2.7 users on platforms other than Windows, that we’re doing something wrong by default.

sodabrew on Dec 9, 2019