Re-bundle gems with Bundler 2.2.0

[mokagio]

Bundler 2.2.0 contains a fix for an issue with optional groups and the .bundle/config file.

The issue resulted in the file being touched every time we'd run a BUNDLE_WITH=screenshots bundle install with a change that, if tracked, would have required all developers to set up all the screenshots automation tooling while that's only needed by platforms developers. See rubygems/rubygems#3708.

Test

1) Checkout this branch.

2) Check your version of Bundler with bundle version, if it's less than 2.2.0, take a note of what version it is (e.g. 2.1.4) then update bundler gem update bundler. If your Bundler already is at the latest version, you can use gem info bundler to see all the installed versions. Ideally, you'll have an older one too, e.g.:

➜ gem info bundler

*** LOCAL GEMS ***

bundler (2.2.0, 2.1.4, 2.0.2, 1.17.3, 1.17.2)

If not, you can always install an older one with gem install bundler:<version>, e.g.: gem install bundler:2.1.4.

3) Run the command resulting in the undesired behavior on the old version of Bundler. E.g:

BUNDLE_WITH=screenshots bundle _2.1.4_ install. (TIL you can pass the version of Bundler to use to bundle like that). You should see that:

• A warning message is shown saying "Warning: the running version of Bundler (2.1.2) is older than the version that created the lockfile (2.2.0). We suggest you to upgrade to the version that created the lockfile by running gem install bundler:2.2.0." That's just default Bundler behavior, not our custom logic, but it's nice to see it because hopefully it'll help people running bundle install being on the expected version of the tool.
• The tracked .bundle/config file changed with the following diff

diff --git a/.bundle/config b/.bundle/config
index 23692288..0bfa20ce 100644
--- a/.bundle/config
+++ b/.bundle/config
@@ -1,2 +1,3 @@
 ---
 BUNDLE_PATH: "vendor/bundle"
+BUNDLE_WITH: "screenshots"

Discard those changes.

3) Run the command that resulted in the undesired behavior on Bundler 2.2.0.

BUNDLE_WITH=screenshots bundle install

Verify that neither the warning nor the .bundle/config change happened.

Review

Only one platform developer required to review these changes, but anyone can perform the review.

Release

These changes do not require release notes.

[peril-automattic]

You can trigger an installable build for these changes by visiting CircleCI here.

[mokagio]

This change happened because Bundler 2.2.0 enables the specific_platform option by default to "properly support gems providing native platform versions with different dependencies than their pure ruby counterparts."

As far as I understand, this should make it easier/faster to run bundle install by not requiring that gems like nokogiri be compiled from source.

I'd expect if someone with an older Mac or an Apple Silicon one were to run bundle install, they'd update the file with their platform, too. This makes me wary that we might get a confused message every now and again by a developer that set up the project and resulted in changes they didn't expect, exactly what this PR is trying to solve.

We can prevent this at the .bundle/config level by adding BUNDLE_FORCE_RUBY_PLATFORM: "true".

But then I wonder if we'd be leaving precious seconds or minutes on the table when running bundle install just to avoid an occasional change to the file 🤔

Then again, we don't often run bundle install, so maybe the time penalty of always building from source is an acceptable compromise for easier maintenance? 🤔 🤔 CI caches the gems so we shouldn't worry about performances there, either.

What do you think?

[mokagio]

I'll proceed to update the other repos once we'll make a decision on this 👍

[jkmassel]

This seems like a win to avoid recompiling a lot on developer machines.

I don't see an issue with occasionally dirtying this file when running on ARM (I don't see anyone bundling this with Windows or Linux anytime soon...)

This seems ok to me as-is?

[loremattei]

I think this is ok now, but we'll regret it as soon as Apple Silicon macs will start to be used as development machines.
Right now, the few Apple Silicon macs around are basically used for testing/investigating/poking, so it's ok to have a dirty repository after bundle install in this case.
But when they'll become standard development machines for someone, I don't think it's a great experience to always have a dirty repository, or to have to remember to manually edit the file if you had to add a gem.
And I image we'll have a mix of Intel and Apple Silicon machines around for quite a long time 😰

wdyt?

[AliSoftware]

I just bundle install'd on WordPressAuthenticator, using bundler 2.2.1 (since that's the version its Gemfile.lock was already locked on) and it added additional darwin platform to the ones that was already there in this repo.

So at least it means that Bundler seems to support multiple binaries platforms in parallel, yes.

[loremattei]

Oh, in this case it looks good 👍

[jkmassel]

This seems like a win to avoid recompiling a lot on developer machines.

I don't see an issue with occasionally dirtying this file when running on ARM (I don't see anyone bundling this with Windows or Linux anytime soon...)

This seems ok to me as-is?

[AliSoftware]

On WC, one of our user who happened to now use bundler 2.2.0 had issues with this PLATFORMS thingy

Found changes from the lockfile, re-resolving dependencies because you added a new platform to your gemfile
[…]

Then got errors when installing; the solution was to make them switch back to bundler 2.1.4.

For more details see this ref: p1608040117493700/1608037157.471800-slack-CC7L49W13

Worth taking a deeper look to ensure this won't cause any trouble in other's setup as well

[mokagio]

@AliSoftware it's possible that Bundler 2.2.1 addresses that kind of problem. There is an "ad hoc fix for platform regression" PR (rubygems/rubygems#4127) in there.

One of the linked issues reports and error with the "Found changes from the lockfile, re-resolving dependencies because..." message.

I tried to run bundle _2.2.0_ install on WC iOS, but it didn't give me any trouble.

In light of that, though, I guess we might want to proceed with caution with this update, though, maybe do it one repo at a time over a period of time so that we can get feedback on whether it works for people or not?

I'll merge this to begin with.

[AliSoftware]

Note that as mentioned in another above comment I've noticed that other repos have already migrated — especially see WordPressAuthenticator-iOS. Could be a good indicator to check if people already have issues with this one and bundler 2.2 for example since it's already landed since… well I don't know when but probably some time now

[mokagio]

@jleandroperez @eshurakov as per discussion above, this PR updates the repo to expect Bundler 2.2.1 to be used to manage our Ruby dependencies.

Now that I merged this, can I ask you to checkout develop and, from the root of the project:

• Run gem update bundler
• Run bundle version; you should see Bundler version 2.2.1 (2020-12-14 commit b98d6b2035) – unless a newer version has been released since I wrote this
• Run bundle install

Does it work smooth for you or do you get errors? Also, is the repo still clean afterwards or has Gemfile.lock or other files changed, and if so, how?

Thanks 🙇