Make no distinction between arm64-darwin-{21,22,23}

[sandstrom]

When running macOS with an ARM processor, our Gemfile.lock looks like this:

PLATFORMS
  aarch64-linux
  arm64-darwin-21
  arm64-darwin-22
  arm64-darwin-23
  arm64-linux
  x86_64-darwin-21
  x86_64-darwin-22
  x86_64-linux

This doesn't make sense to me, there is no discernible difference between 21/22/23.

I think it would make more sense if it looked like this:

PLATFORMS
  aarch64-linux
  arm64-darwin
  arm64-linux
  x86_64-darwin
  x86_64-linux

(i.e. that the mac platform wouldn't get a bump every year)

Semi-related

• Bundler platform locking causes problems out-of-box, on CI, on Heroku etc. #5338

[gstokkink]

Agree with this, not sure what the purpose is of also including the Darwin kernel version in the lockfile, as it's not done for the other architectures either?

@deivid-rodriguez could you maybe shed some light on this? Thanks in advance 😄

[hsbt]

We can easily normalize that with https://github.com/rubygems/rubygems/blob/master/lib/rubygems/platform.rb#L118.

But I'm not sure what breaking impact with this change. Does anyone survey that?

[sandstrom]

I think unknown platforms are just ignored.

Any platform allowed(?)

So for example this platform list in Gemfile.lock:

PLATFORMS
  aarch64-linux
  arm64-darwin-21
  arm64-darwin-22
  arm64-darwin-23
  anything-goes-whatever-works
  arm64-linux
  x86_64-darwin-21
  x86_64-darwin-22
  x86_64-linux

Would not cause any trouble when running bundle install. The only thing it does is sorting it alphabetically.

Automatic cleanup

However, we would be left with some "junk platforms" in the gem lockfile.

Perhaps a temporary addition to bundle install that would look for the pattern arm64-darwin-[/d]{2} and replace them with arm64-darmwin to help with automatic cleanup. Such temporary addition could be removed after e.g. ~1 year.

[deivid-rodriguez]

Agree with this, not sure what the purpose is of also including the Darwin kernel version in the lockfile, as it's not done for the other architectures either?

We just parse what Ruby gives us as RbConfig::CONFIG["arch"].

I agree that Darwin versions are not really different in practice? But not sure. I know people have actually released platform specific gems for different darwin versions but maybe they are actually all equal in code, and that's just due to how RubyGems and Bundler handle platforms right now. I'm also not sure about backwards compatibility.

One thing to note is that since recently, if no darwin version specific precompiled gems are found among resolved gems, Bundler won't lock specific version platforms, but the generic one, like requested here. So this is only a limited problem right now because most popular gems releasing precompiled versions don't ship -darwin-<version> variants, but just generic darwin variants.

[gstokkink]

One thing to note is that since recently, if no darwin version specific precompiled gems are found among resolved gems, Bundler won't lock specific version platforms, but the generic one, like requested here. So this is only a limited problem right now because most popular gems releasing precompiled versions don't ship -darwin-<version> variants, but just generic darwin variants.

Ah, good to know. Seems like nokogiri is one of those.

[starburst997]

Just wanted to chime in as I encountered an issue related to this.

I have a Github Action workflow that worked no problem that uses ruby/setup-ruby with cache enabled and a Gemfile.lock that run on macos-13 runners. Suddenly, without change, I encountered this error:

Your bundle only supports platforms ["x64-mingw-ucrt", "x86_64-linux", "x86_64-darwin-21"] but your
local platform is x86_64-darwin-22. Add the current platform to the lockfile
with
`bundle lock --add-platform x86_64-darwin-22` and try again.

Now, macos-13 are "supposed" to be 22 anyway, the reason why 21 used to work is because that number is embedded at compile time based on whichever platform was used to compile it. setup-ruby previously used macos-12 runner to build, but now are using macos-13 which changed that number, hence the error.

It's pretty annoying that I first need to guess that actual number since running on a specific macOS platform doesn't guarantee the compiler was built on that version but also that suddenly it could change and now I have to add that new platform in all my lockfiles whereas other platforms seems pretty deterministic for that value.

This is an issue for x86_64-darwin not only arm64-darwin.

[deivid-rodriguez]

@starburst997 Yeah, I can see how that can be annoying. I think we'll eventually deprecate -NN darwin platform versions in lockfile, and start ignoring the -NN part everywhere.

For now, we've taken some steps to alleviate this issue:

• Fresh lockfiles don't include -NN platforms by default, unless some locked gem has released a -NN variant matching your platform (but I'm not aware of any gems doing this).
• You can normalize your lockfile by running bundle lock --normalize-platforms or more specifically to only remove the inconvenient platform by running bundle lock --remove-platform <platform-with-version> and then bundle lock --add-platform <platform-without-version>).

[jeremywadsack]

I'm having a problem with this related to building the grpc gem. On my system bundle install is insisting on building a native extension rather than grabbing the arm64-darwin native build already available in Rubygems.

Running bundle platform lists my platform as "arm64-darwin-23".

I installed the latest bundler, hoping that it would "alleviate the issue", but still got the error. When building from a new Gemfile (without any lock file) it tried to build the native extension.

$ bundle --version
Bundler version 2.6.5
$ bundle install     
Fetching gem metadata from https://rubygems.org/........
Installing grpc 1.70.1 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

When I ran bundle lock --normalize-platforms that created the lock file with the platforms that did not include "-23":

PLATFORMS
  aarch64-linux
  arm64-darwin
  ruby
  x86-linux
  x86_64-darwin
  x86_64-linux

However, even with the lock file present,bundle install still tries to build the native extension.

Fetching gem metadata from https://rubygems.org/........
Installing grpc 1.70.1 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

So the lock file seems to be fixed, but my bundler is still trying to install the -NN version of the platform gem.

[deivid-rodriguez]

Can you share your lockfile and ruby version? I don't know why that's happening to you.

[deivid-rodriguez]

The only explanation that I can think of is that you are using Ruby 3.5-dev, which is incompatible with the native gem, that's why I ask about your Ruby version.

[jeremywadsack]

Ruby version:

$ ruby --version
ruby 3.3.7 (2025-01-15 revision be31f993d7) [arm64-darwin23]

Gemfile:

# frozen_string_literal: true

ruby "3.3.7"

source "https://rubygems.org"

gem 'grpc'

Gemfile.lock:

GEM
  remote: https://rubygems.org/
  specs:
    bigdecimal (3.1.9)
    google-protobuf (4.30.0)
      bigdecimal
      rake (>= 13)
    google-protobuf (4.30.0-aarch64-linux)
      bigdecimal
      rake (>= 13)
    google-protobuf (4.30.0-arm64-darwin)
      bigdecimal
      rake (>= 13)
    google-protobuf (4.30.0-x86-linux)
      bigdecimal
      rake (>= 13)
    google-protobuf (4.30.0-x86_64-darwin)
      bigdecimal
      rake (>= 13)
    google-protobuf (4.30.0-x86_64-linux)
      bigdecimal
      rake (>= 13)
    googleapis-common-protos-types (1.18.0)
      google-protobuf (>= 3.18, < 5.a)
    grpc (1.70.1)
      google-protobuf (>= 3.25, < 5.0)
      googleapis-common-protos-types (~> 1.0)
    grpc (1.70.1-aarch64-linux)
      google-protobuf (>= 3.25, < 5.0)
      googleapis-common-protos-types (~> 1.0)
    grpc (1.70.1-arm64-darwin)
      google-protobuf (>= 3.25, < 5.0)
      googleapis-common-protos-types (~> 1.0)
    grpc (1.70.1-x86-linux)
      google-protobuf (>= 3.25, < 5.0)
      googleapis-common-protos-types (~> 1.0)
    grpc (1.70.1-x86_64-darwin)
      google-protobuf (>= 3.25, < 5.0)
      googleapis-common-protos-types (~> 1.0)
    grpc (1.70.1-x86_64-linux)
      google-protobuf (>= 3.25, < 5.0)
      googleapis-common-protos-types (~> 1.0)
    rake (13.2.1)

PLATFORMS
  aarch64-linux
  arm64-darwin
  ruby
  x86-linux
  x86_64-darwin
  x86_64-linux

DEPENDENCIES
  grpc

RUBY VERSION
   ruby 3.3.7p123

BUNDLED WITH
   2.6.5

But it sounds like bundler should be falling back from arm64-darwin-23 to arm64-darwin and find that version of the gem anyway. So this might be a problem with something on my system, unrelated to this issue?