Update dependencies for RUBY_VERSION 3.1.0dev

[zzak]

bundle update nokogiri curses blade after editing Gemfile.lock by hand

nokogiri in particular had a weird version requirement which specified "< 3.1.DEV" for RUBY_VERSION

blade and ncurses weren't compiling with new version of Ruby, so this fixes it.

I also didn't bother updating "BUNDLED WITH".

[zzak]

I'm not sure why these other architectures were removed 🤔

[yahonda]

I think this is expected behavior since nokogiri gem is now precompiled native gem since 1.11.0. Refer sparklemotion/nokogiri#2075 and sparklemotion/nokogiri#2185 From Rails side, what we can do now is waiting for a new version of nokogiri gem after Ruby 3.1.0 is released.

Also, Rails CI actually removes Gemfile.lock then bundle install .

https://github.com/rails/buildkite-config/blob/8b7d116453fa6fcf3075e8a685686ac5b69e2fcb/Dockerfile#L133

    && rm Gemfile.lock && bundle install -j 8 && cp Gemfile.lock tmp/Gemfile.lock.updated \

So, unless we need to bump gem version at Gemfile itself, we do not need to update Gemfile.lock to support Ruby 3.1.0-dev.

[zzak]

@yahonda Hello!

this is expected behavior since nokogiri gem is now precompiled native gem since 1.11.0. Refer sparklemotion/nokogiri#2075 and sparklemotion/nokogiri#2185

I understand that the behavior of nokogiri is to install the precompiled gem for my architecture, but I'm wondering why just bumping from 1.11.1 to 1.11.3 would remove the other architectures from the lock file. Maybe its my version of bundler from ruby HEAD?

It also seems that only this version on x86_64-darwin is affected.

Would it be a big deal to just merge these versions which are working locally? I assume they don't break for existing Ruby versions, but the alternative is having to maintain a dirty Gemfile.lock in my local checkout in order to hack on Rails 🤔

[p8]

I think this is a Bundler issue: rubygems/rubygems#4516

[flavorjones]

👋 Nokogiri maintainer here.

I believe these precompiled versions were removed from the lock file not because you bumped from 1.11.1 to 1.11.3, but because you did the bumping on Ruby 3.1.0dev for which there aren't any precompiled native gems available.

The behavior of modern bundler on Ruby 3.1.0dev will be to use Nokogiri's vanilla ruby platform gem (as opposed to the x86_64-darwin platform gem), and so blow away the other architecture platforms in the lockfile.

I'm not comfortable shipping a precompiled version of Nokogiri that attempts to be compatible with 3.1.0dev, because the Ruby ABI may still change before official 3.1 prereleases, which would cause a gem version I ship today to segfault or otherwise be buggy for future versions of Ruby 3.1. If someone thinks this would be OK to do, I'd love to talk and understand how to safely do this.

If you choose to bump the Nokogiri dependency to cover Ruby 3.1.0dev, please understand that you'll be taking a step backwards to compiling the vanilla ruby platform gem from source, with all the attendant toolchain challenges and the wall-clock time to compile libxml2/libxslt.

[zzak]

@flavorjones Hello Mike! Thanks for taking your time to look into this for me.

After re-reading your message and trying this myself ( 095f5c9 ), I realized what you mean.

We can't have our cake (using Ruby 3.1.dev) without changing Gemfile.lock, TIL.

FWIW: I think this file is there to aid developers working on Rails and probably few of them are using Ruby's master and not some already-released version. So I think it's fine to keep "stable" dependencies in here, and not force packages to adopt unreleased versions of Ruby downstream. It's much easier for me to change a lockfile, than it is to patch a gem.