RFC: Provide easy access to the cross-rubies from the build process

[flavorjones]

Context

Currently, any gem maintainer who wishes to limit the precompiled extensions to only a few recent rubies must set RUBY_CC_VERSION to a specific set of Ruby versions to inform rake-compiler.

Practically, this means that every gem's build process somewhere is hard-coding ruby versions. Some examples:

• nokogiri: https://github.com/sparklemotion/nokogiri/blob/main/.cross_rubies#L1
• sqlite3-ruby: https://github.com/sparklemotion/sqlite3-ruby/blob/flavorjones-dep-sqlite-3.48.0/rakelib/native.rake#L9
• re2: https://github.com/mudge/re2/blob/main/Rakefile#L36

Previously, this was not a big deal because we generally settled on the .0 release for the cross-rubies. However, starting with v1.6.0 we've started upgrading the cross-rubies' patch levels for various reasons. This makes upgrading rake-compiler-dock annoying because now everyone has to update these hard-coded values.

Proposal

I'm proposing that the rake-compiler-dock gem make these cross-ruby versions available to gem maintainers for use at build time.

Specifically I'm proposing (and would like feedback on) a method RakeCompilerDock.cross_rubies which returns a Hash<minor ⇒ patch>, e.g.:

{
  "3.4" => "3.4.1",
  "3.3" => "3.3.7",
  ...
  "2.4" => "2.4.10"
}

Then gems could assemble a correct/valid value for RUBY_CC_VERSIONS using only the minor versions that will be packaged.

I'd love to get a 👍 or 👎 and a comment from folks.

/cc @mudge @stanhu @larskanis

[flavorjones]

Or, I guess, an alternative or additional method might construct the RUBY_CC_VERSION based on minors:

RakeCompilerDock.ruby_cc_version("3.4", "3.3", "3.2", "3.1")
# => "3.4.1:3.3.5:3.2.6:3.1.6"

and potentially even accept Gem::Requirement

RakeCompilerDock.ruby_cc_version(Gem::Requirement.new("~> 3.0"))
# => "3.4.1:3.3.5:3.2.6:3.1.6:3.0.7"

Overkill?

[mudge]

Introducing some sort of higher-level API that either sets RUBY_CC_VERSION or returns the necessary string for it would be useful and make the diff smaller between rake-compiler-dock upgrades.

Given that Ruby version support will always end up being a Requirement in the resulting gems maybe using that API isn't a bad idea but could be an implementation detail, e.g.

RakeCompilerDock.set_ruby_cc_version("~> 3.0")
# internally uses `Gem::Requirement.create` to handle input and filters the supported list of Ruby versions for rake-compiler

[flavorjones]

See #150 for a concrete proposal.

[flavorjones]

Released in Release v1.9.1 / 2025-01-20 · rake-compiler/rake-compiler-dock

[stanhu]

This is great, thanks.

[stanhu]

@flavorjones I should note that for Rust extensions, we also need to match the patch releases here:

• Bump rake-compiler-dock images to v1.8.0 with Ruby patch versions oxidize-rb/rb-sys#489
• Make rb-sys-dock aware of patch releases oxidize-rb/rb-sys#492

The first pull request uses RUBY_CC_VERSION inside a Dockerfile. I suppose we could find a way to inject this dynamically or template it.

With the addition of -gnu and -musl suffixes, we also need to publish aliases for the rbsys Docker images:

• Add support for Docker aliases oxidize-rb/rb-sys#493

[stanhu]

Actually, we can simplify the Dockerfile to omit the patch release and use RakeCompilerDock.cross_rubies in the Ruby script. Let me do that.