Bundler 2.3.21 attempts to update PLATFORMS in Gemfile.lock on bundle exec, fails on read-only filesystem

[lyricsboy]

Describe the problem as clearly as you can

We run our apps with a read-only filesystem in a Docker container.

In many of our apps' Gemfile.lock, we have a PLATFORMS section that lists various platforms we use for development and deployment; we do not typically maintain this list ourselves. Example:

PLATFORMS
  x86_64-darwin-17
  x86_64-darwin-19
  x86_64-darwin-20
  x86_64-linux-musl

As of Bundler 2.3.21, when we run our app using bundle exec, it attempts to write to Gemfile.lock to add the platform relevant for the current system (e.g. linux on the server). Because we're running in a read only file system, this fails with:

Errno::EROFS: Read-only file system @ rb_sysopen - /app/Gemfile.lock

As a workaround, we have found that removing other platforms and adding the ruby platform to Gemfile.lock prevents the issue, but we don't really understand why, or if this is a good general solution.

Did you try upgrading rubygems & bundler?

Yes :)

What were you expecting to happen?

Running bundle exec commands does not attempt to write to Gemfile.lock or any other files.

What actually happened?

Errno::EROFS: Read-only file system @ rb_sysopen - /app/Gemfile.lock

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

Can provide this if needed.

[lyricsboy]

Mysteriously, in another of our apps, we had the ruby platform in Gemfile.lock, but it failed to find a proper version of a native gem dependency at runtime; I used bundle lock --add-platform x86_84-linux to add the runtime platform to the list, and that resolved the gems to include the proper native versions. It also removed ruby from the list of platforms. But when I deployed the app, everything worked! I am further confused.

[deivid-rodriguez]

Hei!

This is more or less expected. When you run bundle exec, Bundler will try to find anything missing locally and if it's there, it happily continues and updates the lockfile with anything that was missing, so that next time it can skip all these extra checks to find and add the missing pieces. That's what's happening this time with the local platform.

The solution on your side is to add the platform of your Linux server to the lockfile. If you enable frozen mode (BUNDLE_FROZEN env variable), which on a read-only file system is almost always what you want, the error should be better since it should tell you the exact command that you need to run to update the Gemfile.lock file.

Regarding your last comment, yes, using ruby as the platform in the Gemfile.lock file may work sometimes, but it may not other times. The better solution is to keep a list of specific platforms that you need.

Anyways, things actionable for us here:

• Consider the better error we give in frozen mode in this case, since a read-only filesystem is implicitly frozen anyways.
• Consider downgrading this error to a warning.

[lyricsboy]

Thanks so much for the clear explanation, this makes sense. I was not previously aware of BUNDLE_FROZEN, but it does indeed sound helpful in our environment. I will share this guidance on the platforms usage with our team.

If you want to leave this issue open to address those items, I'm fine with that.

[la-jamesh]

This has also caused headaches for myself and my teams when using Ruby on AWS Lambda as the lambda filesystem is read only. I think I would also consider downgrading this error to a warning. Great tip on the BUNDLE_FROZEN env var though!

[9mm]

I also noticed this ... I have to bundle install new gems, then bundle update. if I add a gem to gemfile and do bundle update like i usually do, it will remove platforms, yet the other way does not