ruby / ruby/rubygems

Allow `force_ruby_platform` to apply only to some platforms

Open
#5,809 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bundler type: feature request
Dominant language
Ruby
Stars
4k
Forks
1.9k
Avg merge
1d 2h
Merged PRs (30d)
81

Description

Describe the problem as clearly as you can

We have this in our Gemfile:

gem 'grpc', force_ruby_platform: RUBY_PLATFORM =~ /arm64-darwin/

and our platforms are:

PLATFORMS
  arm64-darwin-21
  x86_64-darwin-21
  x86_64-linux

We need to do this because the grpc gem doesn't work on Apple M1 Macbooks unless you compile the gem yourself (hence the force_ruby_platform. Additionally, we do this so that our peers on Apple Intel Macbooks don't have to compile the gem since it can take a very long time to compile on Intel machines.

The problem is that depending on who runs a bundle update ..., the Gemfile.lock changes. Here's a breakdown:

If Gemfile.lock was created from scratch by an M1, it'll look like this:
M1:

     grpc (1.43.1)
       google-protobuf (~> 3.18)
       googleapis-common-protos-types (~> 1.0)

Which means Intel machines will compile (😞). Additionally, if an Intel does a bundle update ... it doesn't add extra platforms.

If Gemfile.lock was created from scratch by an Intel, it'll look like this:
Intel:

     grpc (1.43.1)
       google-protobuf (~> 3.18)
       googleapis-common-protos-types (~> 1.0)
     grpc (1.43.1-x86_64-darwin)
       google-protobuf (~> 3.18)
       googleapis-common-protos-types (~> 1.0)
     grpc (1.43.1-x86_64-linux)
       google-protobuf (~> 3.18)
       googleapis-common-protos-types (~> 1.0)

Which means it works perfectly for both Intel and M1. However, if an M1 does a bundle update, it will remove the extra platforms so that the Gemfile.lock looks like it was generated by an M1 from scratch.

Maybe this is the intended behavior, but it causes a lot of confusion. But it also seems inconsistent for bundle update. Any advice would be appreciated.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Gemfile and Gemfile.lock examples, then reproduce the behavior on arm64-darwin and x86_64-darwin using bundle update. Trace how force_ruby_platform and platform entries are handled during dependency resolution. Done should mean updates preserve the appropriate platform-specific gems while forcing the Ruby platform only where requested.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.