Bundler 2.2.3 generated Gemfile.lock on a mac cannot be used on linux out of the box

[schneems]

Describe the problem as clearly as you can

Here's an example repo: https://github.com/schneems/bundler_223_fails_deploy. It has one dependency rake and the Gemfile.lock was generated by running bundle install on my mac. When I try to use this Gemfile/Gemfile.lock combo it fails:

docker run -it --rm ruby:2.7 bash
git clone https://github.com/schneems/bundler_223_fails_deploy
cd bundler_223_fails_deploy
export BUNDLE_WITHOUT='development:test'
export BUNDLE_DEPLOYMENT=1
export BUNDLE_PATH=vendor/bundle
bundle install -j4

Then

 bundle exec rake -P
bundler: failed to load command: rake (/bundler_223_fails_deploy/vendor/bundle/ruby/2.7.0/bin/rake)
Gem::Exception: can't find executable rake for gem rake. rake is not currently included in the bundle, perhaps you meant to add it to your Gemfile?
  /usr/local/lib/ruby/2.7.0/bundler/rubygems_integration.rb:374:in `block in replace_bin_path'
  /usr/local/lib/ruby/2.7.0/bundler/rubygems_integration.rb:402:in `block in replace_bin_path'
  /bundler_223_fails_deploy/vendor/bundle/ruby/2.7.0/bin/rake:23:in `<top (required)>'

What were you expecting to happen?

I expect that a Gemfile.lock produced on mac can also work on linux

What actually happened?

The gem appears to install, but then it cannot be loaded.

Extra context

Either adding ruby to the PLATFORMS section or x86_64-linux fixes the issue, but this is not immediately clear.

If not included with the output of your command, run bundle env and paste the output below

bundle env (on my mac)

## Environment

Bundler       2.2.3
  Platforms   ruby, x86_64-darwin-19
Ruby          3.0.0p0 (2020-12-25 revision 95aff214687a5e12c3eb57d056665741e734c188) [x86_64-darwin19]
  Full Path   /Users/rschneeman/.rubies/ruby-3.0.0/bin/ruby
  Config Dir  /Users/rschneeman/.rubies/ruby-3.0.0/etc
RubyGems      3.2.3
  Gem Home    /Users/rschneeman/.gem/ruby/3.0.0
  Gem Path    /Users/rschneeman/.gem/ruby/3.0.0:/Users/rschneeman/.rubies/ruby-3.0.0/lib/ruby/gems/3.0.0
  User Home   /Users/rschneeman
  User Path   /Users/rschneeman/.gem/ruby/3.0.0
  Bin Dir     /Users/rschneeman/.gem/ruby/3.0.0/bin
Tools         
  Git         2.28.0
  RVM         not installed
  rbenv       not installed
  chruby      0.3.9

Bundler Build Metadata

Built At          2020-12-22
Git SHA           29dc3c8398
Released Version  true

Bundler settings

jobs
  Set for the current user (/Users/rschneeman/.bundle/config): 8
build.nokogiri
  Set for the current user (/Users/rschneeman/.bundle/config): "--use-system-libraries"
gem.test
  Set for the current user (/Users/rschneeman/.bundle/config): "rspec"
gem.mit
  Set for the current user (/Users/rschneeman/.bundle/config): true
gem.coc
  Set for the current user (/Users/rschneeman/.bundle/config): true
--path
  Set for the current user (/Users/rschneeman/.bundle/config): "vendor/"

Gemfile

Gemfile

source 'https://rubygems.org'
gem 'rake'

Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:
    rake (13.0.3)

PLATFORMS
  x86_64-darwin-19

DEPENDENCIES
  rake

BUNDLED WITH
   2.2.3

bundle env (on docker)

## Environment

Bundler       2.1.4
  Platforms   ruby, x86_64-linux
Ruby          2.7.2p137 (2020-10-01 revision 5445e0435260b449decf2ac16f9d09bae3cafe72) [x86_64-linux]
  Full Path   /usr/local/bin/ruby
  Config Dir  /usr/local/etc
RubyGems      3.1.4
  Gem Home    /usr/local/bundle
  Gem Path    /root/.gem/ruby/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/local/bundle
  User Home   /root
  User Path   /root/.gem/ruby/2.7.0
  Bin Dir     /usr/local/bundle/bin
Tools
  Git         2.20.1
  RVM         not installed
  rbenv       not installed
  chruby      not installed

Bundler Build Metadata

Built At          2021-01-11
Git SHA           unknown
Released Version  false

Bundler settings

jobs
  Set for your local app (/usr/local/bundle/config): 4
without
  Set for your local app (/usr/local/bundle/config): [:development, :test]
  Set via BUNDLE_WITHOUT: [:development, :test]
app_config
  Set via BUNDLE_APP_CONFIG: "/usr/local/bundle"
deployment
  Set via BUNDLE_DEPLOYMENT: true
silence_root_warning
  Set via BUNDLE_SILENCE_ROOT_WARNING: true
path
  Set via BUNDLE_PATH: "vendor/bundle"

Gemfile

Gemfile

source 'https://rubygems.org'
gem 'rake'

Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:
    rake (13.0.3)

PLATFORMS
  x86_64-darwin-19

DEPENDENCIES
  rake

BUNDLED WITH
   2.2.3

[deivid-rodriguez]

Yes, this is correct.

Sorry, I've been going back and forth here trying to get a correct (and as fast as previously) resolution, while keeping this thing usable, but yeah right now if you want to develop under a platform and deploy to a different one (linux in this example), you'd need to run bundle lock --add-platform <platform_to_deploy_to> and commit the resulting lockfile.

I could try restoring the RUBY platform as a fallback but you wouldn't get any platform specific gems unless you explicitly add the platform you want to deploy to.

[schneems]

Thanks for the ultra fast response!

Workaround

I think in the short term I'm going to try to upgrade Heroku customers to Bundler 2.2.3 which provides a warning for this out of the box.

remote: -----> Installing dependencies using bundler 2.2.3
remote:        Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 bundle install -j4
remote:        Your bundle only supports platforms ["x86_64-darwin-19"] but your local platform
remote:        is x86_64-linux. Add the current platform to the lockfile with `bundle lock
remote:        --add-platform x86_64-linux` and try again.
remote:        Bundler Output: Your bundle only supports platforms ["x86_64-darwin-19"] but your local platform
remote:        is x86_64-linux. Add the current platform to the lockfile with `bundle lock
remote:        --add-platform x86_64-linux` and try again.

Then customers will be unblocked in the short term (provided I don't have to rollback due to a yet-to-be-found regression).

Future musings

As a feature of bundler, I want to be able to either have bundler default to linux as a secondary platform or have some way of specifying it globally.

This change in behavior with 2.2.3 means a lot of existing tutorials for deploying Ruby apps now no longer work. Ideally, I would like to get them back to being valid as many are not maintained and will never be updated. For those that can be updated, it would be ideal to not have to add an extra step.

I'm happy to help brainstorm here or provide support if I can.

[deivid-rodriguez]

Right, I think I can probably restore the old behaviour as a last resort without losing any of the good stuff of locking the specific platform in the lockfile. I'll work on it tomorrow and keep you posted.

[schneems]

Thanks! We have code on the Heroku buildpack that deletes the Gemfile.lock if we see it's locked to the windows platform. It would be exciting to get rid of that functionality and get deterministic deploys for devs using windows. I appreciate you working on this area.

[deivid-rodriguez]

Hi @schneems!

So, I've been sleeping on this issue, and I think what we have now is quite good to be honest. Let me try to explain why we did this, and why I believe it's a good thing.

Context

In previous bundler versions, bundler didn't consider platforms for resolution at all. What bundler would previously do is to resolve dependencies without considering platforms, and then at installation time, pick up platform specific variants with the same version as the resolved version if they exist. That approach had several problems:

• Resolution correctness. Resolution would be incorrect sometimes, since it can happen that for the same gem and version number, a platform specific variant can have different dependencies than the standard variant. Without considering the specific platform for resolution, we might not get a valid set of dependencies, since new unconsidered constraints can be introduced after resolution. This is rare, but not that rare. For example, nokogiri recently released prerelease versions meeting this condition.

• Safety. Not only resolution is invalid, but the previous approach meant resolution was not actually fully locked. Say you're using foo-1.2.0 in your application. You have a lockfile specifically locking foo to 1.2.0, you test it in CI and in your staging environment, and it's all good. Then someone pushes foo-1.2.0-x86_64-linux to rubygems.org, a platform specific variant for foo 1.2.0, that, for example, has a critical bug, or that was pushed by a malicious actor. Then when you deploy to production, foo-1.2.0-x86_64-linux will be installed because it matches the running platform more closely. To me this is totally unexpected, if you have a Gemfile.lock file, no third party release should be able to change the set of third party code that you run.

Resolving for the specific running platform and recording the exact resolution in the lockfile fixes the above issues.

Current situation

• I believe we can improve on it but the current error message is not too bad, and allows for easily fixing the issue.

• This error will only happen if you are using bundler in frozen mode (with BUNDLE_FROZEN or BUNDLE_DEPLOYMENT). If you're not using frozen mode, then bundler will automatically re-resolve using the running platform if it's not already in the lockfile. If you are using frozen mode, I believe it means that you explicitly want to avoid the second issue I mentioned above, so... an error if that can't be guaranteed seems appropriate.

• Yes, some tutorials could be broken by this, but only under some circumstances:

  • If the tutorial provides a Gemfile.lock then bundler will respect that. Meaning, if the lockfile was generated with previous bundler versions, bundler will still fallback to how it worked in previous versions. But if you generate a lockfile from scratch, then it will use the more secure and correct mode.
  • If the tutorial does not set frozen mode, then bundler will re-resolve and just work as mentioned above.
  • If the two above are not met, yes, things can break, but just like they could break if there's a new Rails release or whatever dependencies the tutorial uses. I believe that's acceptable, but I'm willing to help updating any popular tutorials that we detect to be affected by this.

Please let me know what you think.

[schneems]

I think that's reasonable to keep this in there. As you mentioned it's more specific and safer. I am interested though in polishing the "out of the box" experience.

I'm thinking to how bundler was added to Ruby by default so the annoyance of hitting the no such command "bundle" doesn't get hit. It's a relatively small improvement as it only needs to be installed once per ruby version, but the "out of the box" experience is dramatically improved (in my opinion).

In my ideal world, a project with a Gemfile.lock would "just work ™️" on deployment, so it seems that ideally, we could find some way to get the x86_64-linux platform in there either with lower or no cost to the developer.

Spitballing some ideas:

• Prompt the user when there's only one platform and it's windows or mac
• Allow for setting a global config: bundle config --global set deploy_platform_default x86_64-linux
• Add x86_64-linux by default out of the box and allow users to overwrite the default
• Some combination of the above?

Do any of those sound remotely appealing or workable?

What I'm striving for is that if a developer does every step to create an app and deploy it "by the book" that it works "out of the box". Like this sentiment: https://twitter.com/searls/status/1344277289840873472.

If not I would be interested to hear more about your considerations. Also if you prefer we could move this over to slack or a zoom/hangout chat if you want higher fidelity. I'm happy to bounce ideas around if you think it could be helpful.

[schneems]

Also some feedback from a customer who develops on Linux already.

I asked if this fixed their issue:

bundle lock --add-platform x86_64-linux
bundle install
git add . ; git commit -m fix

They responded:

No, this doesn't fix it as it doesn't change my Gemfile.lock at all. I'm working locally on Ubuntu, so this platform is already there. The one that is missing is "ruby" and this fixes it for me: "bundle lock --add-platform ruby"

BTW, I tested with bundler 2.2.5

Before (does not work on heroku)

PLATFORMS
x86_64-linux

After (works on heorku)

PLATFORMS
ruby
x86_64-linux

[deivid-rodriguez]

@schneems I'll respond to your comments as soon as I can, but if you can report that issue separately in the mean time, I appreciate it.

[schneems]

Can do. Thanks!

[deivid-rodriguez]

Hi @schneems.

I'm not opposed to adding some configuration so that users can specify the set of platforms they want to support. I had the idea of adding a platforms DSL in the Gemfile where people can specify the target platforms they want to support.

We currently have the issue though that the resolver can handle platforms correctly, but at the same time, resolving for multiple platforms by default is sometimes very inefficient. That's why we currently resolve only for the current platform and if the user wants to add more platforms, for example, to get ready for deploying under a different platform that the one they are developing on, then she can add them manually. I'm currently working on fixing these issues so that I can at least restore resolving for the RUBY platform by default as a fallback.

Until I can fix these issues, would adding the deployment platform on the fly to the lockfile if not present work for you? Basically, run bundle lock --add-platform x86_86-linux before setting deployment mode and running bundle install, so that you make sure the platform we are deploying too is present in the lockfile, no matter what. This solution would also work for Gemfiles generated on Windows I believe.

[schneems]

That's do-able. We've got some deploy freezes right now, but I can work something up. My concern is that a temporary workaround ends up being permanent. Like the same way we have to strip out BUNDLE WITH information from the Gemfile.lock.

I think adding this platform on our end defeats the security and resolution-correctness purpose you mentioned before as they can get different versions in prod than at development time. I would perhaps be easier to just not enable BUNDLE_DEPLOYMENT=1 env var. Though worse (for safety/predictability concerns). In the long run I do want to be able to support windows deployment without deleting the Gemfile.lock. If I'm adding x86_64-linux still then I think I'm pretty much back to where we are today.

Options on my end

Here's some brainstorming about options I can take moving forwards with the consequences (good and bad) listed below each. For reference deploying, CodeTriage takes 2m0.919s which also includes running a release phase

Do nothing (zeroeth option)

• Preserves dev/prod parity behavior
• Requires the user take an extra step for successful deploy
• Adds ~0 seconds to deploy
• No feedback to the user is frustrating, a very bad experience

Turn off "deployment mode" on Heroku

• Does NOT preserve dev/prod dependency behavior
• Does NOT Require the user take an extra step for successful deploy
• Adds ~0 seconds to deploy
• Introduces other security holes such as someone updating their gemfile but not running bundle install and trying to deploy. A bad experience.

Auto-add x86_64-linux before bundle install on Heroku

• Does NOT preserve dev/prod dependency behavior
• Does NOT Require the user take an extra step for successful deploy
• Gets us close to where we are today for < bundler 2.2 generated lockfiles for user experience, also for security dev/prod behavior
• Adds ~4 seconds to deploy (for CodeTriage sized Gemfile.lock) [this is a 3.0% increase in deploy time]

$ time bundle lock --add-platform x86_64-linux --add-platform ruby
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies.....
Writing lockfile to /Users/rschneeman/Documents/projects/codetriage/Gemfile.lock

real  0m4.263s

• We possibly could only run this conditionally based on the output of bundle platform which takes 0.3 seconds to execute

Upgrade bundler to 2.2.5 for all users on Heroku

• Preserves dev/prod dependency behavior
• Does Require the user take an extra step for successful deploy
• Adds ~0 seconds to deploy
• Gives users a better error message telling them what to do
• Bundler upgrades historically cause platform issues which is why we restrict bundler versions
  • We want to eventually upgrade users, but need for 1 in a million bugs to be sussed out and fixed (as they happen quite often for us).

Detect bundle platform and error/warn on Heroku

• Preserves dev/prod dependency behavior
• Does NOT Require the user take an extra step for successful deploy
• Adds 0.3 seconds to every deploy [0.25% increase in deploy time]
• Gives users a better error message telling them what to do
• Output is not delivered in a machine readable standard, so there may be complications regexing it

Recap

I'm not sure. There's tradeoffs with all of these. I think I'll need to explore multiple options forward. Likely some combination of:

• Upgrading bundler version
• Detecting/warning on bundle platform
• Auto-adding some platforms based off of bundle platform though I'm still hesitant to do this for fear it becomes a long term expected feature of the platform. I'll have to couple this with heavy warnings.

[tomdulin]

Reading the comments, I am running into the same issue even after running the bundler lock command in several variations (/w ruby, /wo ruby) doesnt matter, still get the same error:

remote: -----> Building on the Heroku-20 stack
remote: -----> Ruby app detected
remote: -----> Installing bundler 2.2.11
remote: -----> Removing BUNDLED WITH version in the Gemfile.lock
remote: -----> Compiling Ruby/Rails
remote: -----> Using Ruby version: ruby-3.0.0
remote: -----> Installing dependencies using bundler 2.2.11
remote: Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 bundle install -j4
remote: Your bundle only supports platforms ["x86_64-darwin-20"] but your local platform
remote: is x86_64-linux. Add the current platform to the lockfile with bundle lock remote: --add-platform x86_64-linux and try again.
remote: Bundler Output: Your bundle only supports platforms ["x86_64-darwin-20"] but your local platform
remote: is x86_64-linux. Add the current platform to the lockfile with bundle lock remote: --add-platform x86_64-linux and try again.
remote:
remote: !
remote: ! Failed to install gems via Bundler.
remote: !
remote: ! Push rejected, failed to compile Ruby app.

gemfile.lock:
...
PLATFORMS
x86_64-linux
...

running
ruby 2.6
rails 3.0.0
bundler 2.2.11

Not sure what I am missing here, any thoughts?

[raldred]

We had this symptom and it was actually caused by our Gemfile lock having CLRF line endings which wasn't being parsed by the build back correctly. However i believe that has now been fixed by the build pack maintainer

…

On Sat, 6 Mar 2021, 01:30 Tom Dulin, ***@***.***> wrote: Reading the comments, I am running into the same issue even after running the bundler lock command in several variations (/w ruby, /wo ruby) doesnt matter, still get the same error: remote: -----> Building on the Heroku-20 stack remote: -----> Ruby app detected remote: -----> Installing bundler 2.2.11 remote: -----> Removing BUNDLED WITH version in the Gemfile.lock remote: -----> Compiling Ruby/Rails remote: -----> Using Ruby version: ruby-3.0.0 remote: -----> Installing dependencies using bundler 2.2.11 remote: Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 bundle install -j4 remote: Your bundle only supports platforms ["x86_64-darwin-20"] but your local platform remote: is x86_64-linux. Add the current platform to the lockfile with bundle lock remote: --add-platform x86_64-linux and try again. remote: Bundler Output: Your bundle only supports platforms ["x86_64-darwin-20"] but your local platform remote: is x86_64-linux. Add the current platform to the lockfile with bundle lock remote: --add-platform x86_64-linux and try again. remote: remote: ! remote: ! Failed to install gems via Bundler. remote: ! remote: ! Push rejected, failed to compile Ruby app. gemfile.lock: ... PLATFORMS x86_64-linux ... running ruby 2.6 rails 3.0.0 bundler 2.2.11 Not sure what I am missing here, any thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4269 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAJB2CV73TCRNAMHEWHIQDTCGARVANCNFSM4V52ZOPA> .

[saqib1324]

Also some feedback from a customer who develops on Linux already.

I asked if this fixed their issue:

bundle lock --add-platform x86_64-linux
bundle install
git add . ; git commit -m fix

They responded:

No, this doesn't fix it as it doesn't change my Gemfile.lock at all. I'm working locally on Ubuntu, so this platform is already there. The one that is missing is "ruby" and this fixes it for me: "bundle lock --add-platform ruby"
BTW, I tested with bundler 2.2.5
Before (does not work on heroku)

PLATFORMS
x86_64-linux

After (works on heorku)

PLATFORMS
ruby
x86_64-linux

This fixed for me on macOS Catalina

[duffyjp]

Like so many others, we dev on Mac and deploy to Linux. I've been running bundle lock --add-platform x86_64-linux as needed but we keep tripping over that.

Are there plans to add desired platforms to the Gemfile so it's automatic?

[baelter]

We got devs on mac and linux and deploy to heroku. Our solution has been to bundle config set force_ruby_platform true on the macs.

[gregschwartz]

Think I'm running into a similar issue. It started 3 days ago, after updating bundle, which moved my project from 1.17.2 to 1.17.3. This is on ruby 2.6.3p62. Have tried running everything suggested in this thread:

bundle lock --add-platform x86_64-linux 
bundle lock --add-platform ruby
bundle config set force_ruby_platform true
bundle install
bundle update

I'm on MacOS Big Sur 11.2.2, and Heroku still installs then removes all my gems:

-----> Building on the Heroku-18 stack
-----> Using buildpack: heroku/ruby
-----> Ruby app detected
-----> Installing bundler 1.17.3
-----> Removing BUNDLED WITH version in the Gemfile.lock
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.6.3
-----> Installing dependencies using bundler 1.17.3
       Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 BUNDLE_GLOBAL_PATH_APPENDS_RUBY_SCOPE=1 bundle install -j4
       The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.
       Fetching gem metadata from https://rubygems.org/...........
       Fetching rake 13.0.3
       Installing rake 13.0.3
       Fetching concurrent-ruby 1.1.8
       Using thread_safe 0.3.6
       Fetching zeitwerk 2.4.2
       Fetching minitest 5.14.4
       Installing minitest 5.14.4
       Installing concurrent-ruby 1.1.8
       Installing zeitwerk 2.4.2
       Using builder 3.2.4
       Fetching erubi 1.10.0
       Fetching mini_portile2 2.5.0
       Installing mini_portile2 2.5.0
       Installing erubi 1.10.0
       Fetching racc 1.5.2
       Using crass 1.0.6
       Using rack 2.2.3
       Fetching nio4r 2.5.7
       Installing racc 1.5.2 with native extensions
       Installing nio4r 2.5.7 with native extensions
       Using websocket-extensions 0.1.5
       Fetching marcel 1.0.1
       Installing marcel 1.0.1
       Fetching mini_mime 1.1.0
       Installing mini_mime 1.1.0
       Fetching public_suffix 4.0.6
       Installing public_suffix 4.0.6
       Using execjs 2.7.0
       Using bcrypt 3.1.16
       Fetching msgpack 1.4.2
       Installing msgpack 1.4.2 with native extensions
       Using popper_js 1.16.0
       Using method_source 1.0.0
       Fetching thor 1.1.0
       Installing thor 1.1.0
       Fetching ffi 1.15.0
       Installing ffi 1.15.0 with native extensions
       Using tilt 2.0.10
       Using bundler 1.17.3
       Using orm_adapter 0.5.0
       Fetching faraday-excon 1.1.0
       Installing faraday-excon 1.1.0
       Fetching faraday-net_http 1.0.1
       Installing faraday-net_http 1.0.1
       Fetching faraday-net_http_persistent 1.1.0
       Installing faraday-net_http_persistent 1.1.0
       Using multipart-post 2.1.1
       Fetching ruby2_keywords 0.0.4
       Installing ruby2_keywords 0.0.4
       Fetching jwt 2.2.3
       Installing jwt 2.2.3
       Using memoist 0.16.2
       Using multi_json 1.15.0
       Using os 1.1.1
       Using httpclient 2.8.3
       Fetching json 2.5.1
       Installing json 2.5.1 with native extensions
       Fetching libv8-node 15.14.0.0 (x86_64-linux-musl)
       Installing libv8-node 15.14.0.0 (x86_64-linux-musl)
       Using pg 1.2.3
       Fetching tzinfo 1.2.9
       Installing tzinfo 1.2.9
       Using rack-test 1.1.0
       Using warden 1.2.9
       Fetching i18n 1.8.10
       Installing i18n 1.8.10
       Using websocket-driver 0.7.3
       Using sprockets 4.0.2
       Using mail 2.7.1
       Using addressable 2.7.0
       Fetching autoprefixer-rails 10.2.4.0
       Installing autoprefixer-rails 10.2.4.0
       Fetching puma 4.3.7
       Installing puma 4.3.7 with native extensions
       Fetching nokogiri 1.11.3 (x86_64-linux)
       Installing nokogiri 1.11.3 (x86_64-linux)
       Fetching faraday 1.4.1
       Installing faraday 1.4.1
       Fetching bootsnap 1.7.4
       Installing bootsnap 1.7.4 with native extensions
       Fetching mini_racer 0.4.0
       Installing mini_racer 0.4.0 with native extensions
       Fetching activesupport 6.0.3.6
       Installing activesupport 6.0.3.6
       Using sassc 2.4.0
       Fetching loofah 2.9.1
       Installing loofah 2.9.1
       Fetching signet 0.15.0
       Installing signet 0.15.0
       Fetching twilio-ruby 5.52.0
       Installing twilio-ruby 5.52.0
       Using rails-dom-testing 2.0.3
       Using globalid 0.4.2
       Fetching activemodel 6.0.3.6
       Installing activemodel 6.0.3.6
       Using rails-html-sanitizer 1.3.0
       Fetching googleauth 0.16.1
       Installing googleauth 0.16.1
       Fetching activejob 6.0.3.6
       Fetching activerecord 6.0.3.6
       Installing activejob 6.0.3.6
       Fetching actionview 6.0.3.6
       Installing actionview 6.0.3.6
       Installing activerecord 6.0.3.6
       Using firebase 0.2.8
       Fetching actionpack 6.0.3.6
       Installing actionpack 6.0.3.6
       Fetching actioncable 6.0.3.6
       Fetching actionmailer 6.0.3.6
       Installing actioncable 6.0.3.6
       Installing actionmailer 6.0.3.6
       Fetching railties 6.0.3.6
       Fetching sprockets-rails 3.2.2
       Installing sprockets-rails 3.2.2
       Fetching activestorage 6.0.3.6
       Installing railties 6.0.3.6
       Installing activestorage 6.0.3.6
       Fetching actionmailbox 6.0.3.6
       Installing actionmailbox 6.0.3.6
       Fetching actiontext 6.0.3.6
       Installing actiontext 6.0.3.6
       Using sassc-rails 2.1.2
       Using responders 3.0.1
       Using jquery-rails 4.4.0
       Fetching rails 6.0.3.6
       Fetching bootstrap 4.5.3
       Installing rails 6.0.3.6
       Using devise 4.7.3
       Using sass-rails 6.0.0
       Using simple_token_authentication 1.17.0
       Installing bootstrap 4.5.3
       Bundle complete! 21 Gemfile dependencies, 83 gems now installed.
       Gems in the groups development and test were not installed.
       Bundled gems are installed into `./vendor/bundle`
       Removing marcel (0.3.3)
       Removing activesupport (6.0.3.2)
       Removing mini_portile2 (2.4.0)
       Removing msgpack (1.3.3)
       Removing mini_racer (0.3.1)
       Removing actionpack (6.0.3.2)
       Removing mini_mime (1.0.2)
       Removing json (2.3.1)
       Removing nio4r (2.5.2)
       Removing tzinfo (1.2.7)
       Removing erubi (1.9.0)
       Removing autoprefixer-rails (10.0.1.0)
       Removing libv8-8.4.255.0-x86_64 (linux)
       Removing rails (6.0.3.2)
       Removing activestorage (6.0.3.2)
       Removing rake (13.0.1)
       Removing twilio-ruby (5.40.0)
       Removing actionview (6.0.3.2)
       Removing puma (4.3.5)
       Removing loofah (2.6.0)
       Removing activerecord (6.0.3.2)
       Removing zeitwerk (2.4.0)
       Removing faraday (1.0.1)
       Removing sprockets-rails (3.2.1)
       Removing googleauth (0.13.1)
       Removing actioncable (6.0.3.2)
       Removing signet (0.14.0)
       Removing public_suffix (4.0.5)
       Removing bootstrap (4.5.2)
       Removing i18n (1.8.5)
       Removing activejob (6.0.3.2)
       Removing bootsnap (1.4.8)
       Removing minitest (5.14.1)
       Removing actionmailer (6.0.3.2)
       Removing railties (6.0.3.2)
       Removing ffi (1.13.1)
       Removing mimemagic (0.3.5)
       Removing nokogiri (1.10.10)
       Removing concurrent-ruby (1.1.7)
       Removing thor (1.0.1)
       Removing actionmailbox (6.0.3.2)
       Removing jwt (2.2.2)
       Removing activemodel (6.0.3.2)
       Removing actiontext (6.0.3.2)
       Bundle completed (38.72s)
       Cleaning up the bundler cache.
       The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.
       Could not find libv8-node-15.14.0.0 in any of the sources
-----> Installing node-v12.16.2-linux-x64
-----> Detecting rake tasks
 !
 !     Could not detect rake tasks
 !     ensure you can run `$ bundle exec rake -P` against your app
 !     and using the production group of your Gemfile.
 !     /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/spec_set.rb:91:in `block in materialize': Could not find libv8-node-15.14.0.0 in any of the sources (Bundler::GemNotFound)
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/spec_set.rb:85:in `map!'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/spec_set.rb:85:in `materialize'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/definition.rb:170:in `specs'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/definition.rb:237:in `specs_for'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/definition.rb:226:in `requested_specs'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/runtime.rb:108:in `block in definition_method'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/runtime.rb:20:in `setup'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler.rb:107:in `setup'
 !     from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/setup.rb:20:in `<top (required)>'
 !     from /tmp/build_15eb78ec/vendor/ruby-2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
 !     from /tmp/build_15eb78ec/vendor/ruby-2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
 !     from /tmp/build_15eb78ec/config/boot.rb:3:in `<top (required)>'
 !     from /tmp/build_15eb78ec/bin/rake:7:in `require_relative'
 !     from /tmp/build_15eb78ec/bin/rake:7:in `<main>'
 !
/tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/helpers/rake_runner.rb:106:in `load_rake_tasks!': Could not detect rake tasks (LanguagePack::Helpers::RakeRunner::CannotLoadRakefileError)
ensure you can run `$ bundle exec rake -P` against your app
and using the production group of your Gemfile.
/tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/spec_set.rb:91:in `block in materialize': Could not find libv8-node-15.14.0.0 in any of the sources (Bundler::GemNotFound)
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/spec_set.rb:85:in `map!'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/spec_set.rb:85:in `materialize'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/definition.rb:170:in `specs'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/definition.rb:237:in `specs_for'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/definition.rb:226:in `requested_specs'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/runtime.rb:108:in `block in definition_method'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/runtime.rb:20:in `setup'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler.rb:107:in `setup'
	from /tmp/build_15eb78ec/vendor/bundle/ruby/2.6.0/gems/bundler-1.17.3/lib/bundler/setup.rb:20:in `<top (required)>'
	from /tmp/build_15eb78ec/vendor/ruby-2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /tmp/build_15eb78ec/vendor/ruby-2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /tmp/build_15eb78ec/config/boot.rb:3:in `<top (required)>'
	from /tmp/build_15eb78ec/bin/rake:7:in `require_relative'
	from /tmp/build_15eb78ec/bin/rake:7:in `<main>'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/ruby.rb:1030:in `rake'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails4.rb:78:in `block (2 levels) in run_assets_precompile_rake_task'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:190:in `log'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails4.rb:72:in `block in run_assets_precompile_rake_task'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:18:in `block (2 levels) in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:40:in `yield_with_block_depth'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:17:in `block in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/vendor/ruby/heroku-18/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:16:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:50:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:46:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails4.rb:71:in `run_assets_precompile_rake_task'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/ruby.rb:112:in `block (2 levels) in compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/ruby.rb:1051:in `allow_git'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/ruby.rb:105:in `block in compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:18:in `block (2 levels) in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:40:in `yield_with_block_depth'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:17:in `block in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/vendor/ruby/heroku-18/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:16:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:50:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:46:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/ruby.rb:91:in `compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails2.rb:62:in `block in compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:18:in `block (2 levels) in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:40:in `yield_with_block_depth'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:17:in `block in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/vendor/ruby/heroku-18/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:16:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:50:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:46:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails2.rb:60:in `compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails3.rb:42:in `block in compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:18:in `block (2 levels) in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:40:in `yield_with_block_depth'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:17:in `block in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/vendor/ruby/heroku-18/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:16:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:50:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:46:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails3.rb:41:in `compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails4.rb:35:in `block in compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:18:in `block (2 levels) in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:40:in `yield_with_block_depth'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:17:in `block in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/vendor/ruby/heroku-18/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:16:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:50:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:46:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails4.rb:34:in `compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails6.rb:20:in `block in compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:18:in `block (2 levels) in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:40:in `yield_with_block_depth'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:17:in `block in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/vendor/ruby/heroku-18/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:16:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:50:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:46:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/rails6.rb:18:in `compile'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/bin/support/ruby_compile:20:in `block (2 levels) in <main>'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/base.rb:190:in `log'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/bin/support/ruby_compile:19:in `block in <main>'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:35:in `block in trace'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:18:in `block (2 levels) in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:40:in `yield_with_block_depth'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:17:in `block in instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/vendor/ruby/heroku-18/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:16:in `instrument'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/lib/language_pack/instrument.rb:35:in `trace'
	from /tmp/codon/tmp/buildpacks/50d5eddf222a9b7326028041d4e6509f915ccf2c/bin/support/ruby_compile:15:in `<main>'
 !     Push rejected, failed to compile Ruby app.
 !     Push failed

Any ideas would be appreciated, otherwise I'll just downgrade using these instructions.

[hartly97]

Upgraded from rails 6.0.3 to 'rails', '~> 6.1', '>= 6.1.3.2'
Upgraded bundler to 2.2.13
bundle lock --add-platform ruby
bundle lock --add-platform x86_64-linux
Doing all three resolved the issue for me. The first three failed pushing to heroku. After the addition of Ruby the push was successful.

The downgrade instructions gregschwartz mentioned above didn't work for me.

[tekpriest]

My GemFile.lock had only

PLATFORMS
    x86_64-darwin-19

Running bundle lock --add-platform x86_64-linux automatically added x86_64-linux
git add .; git commit -m "fix"; git push Issue fixed for me

[daniellimapro]

bundle lock --add-platform <platform_to_deploy_to>

its works for me. great!

[nroose]

Just want to say here that this whole thing was pretty bad. Seems like adding this level of granularity of the platform to the Gemfile.lock was just a bad idea. Dependencies became an order of magnitude more complicated unnecessarily and only cause problems for us and didn't solve anything. The issue we are having is that the dependency tree for grpc seems to be broken for at least one platform - alpine. And so we have to build with something else that happens to fill in the right dependency, which, I think at this time might be the m1 mac. This is kinda a silly thing that just seems to come out of this gross overcomplication.

[deivid-rodriguez]

#5700 should fix this issue, feel free to give it a try!

[markeissler]

Maybe I'm missing something completely here but...

Why are the proposed fixes centered around changing the Gemfile.lock file directly? That file is derived from specifications in the Gemfile. That would indicate to me there should be the ability to specify target platforms from within the Gemfile itself so if you remove the Gemfile.lock (which you should be able to do) then just running bundle install will get you back to where you were before including the platform specifications.

Perhaps another option to consider is that BUNDLE_PLATFORM could be configurable from an environment variable. Everyone could just set a global value for their machine so that the correct platform is set for the bundler for day to day work but and when creating a deployment build a different value could be set.

I get it that people want things to be "automatic" but for anyone that needs to support multiple OS and architecture in projects that are not ruby (as I do) this is frequently a build configuration matter that simply becomes a different target in a Makefile or the addition of a step in a CI config.

NOTE: Since my deployment builds all take place in Docker containers I could just have a step that runs the bundle lock --add-platform x86_64-linux-musl but then the question becomes why do the other platforms (e.g. arm64-darwin-21) need to be saved to the Gemfile.lock file in the first place when my target has changed to x86_64-linux-musl?

Right now I support arm64 and x86_64 targets for both macOS and Linux across multiple projects. In those projects, a simple make image/linux_amd64 gets me the deployment artifact I need without having to change a checked-in file and without including any artifacts that have nothing to do with the intended deployment env. I don't see a good reason as to why ruby apps would need to follow some other model for supporting different architectures.