Consider pulling bundler version from lock file

[JPrevost]

The support for using .ruby-version instead of having to supply it directly is so nice. Thanks!

Would you consider doing something similar with the bundler version from Gemfile.lock?

BUNDLED WITH
   2.1.4

It's not a huge deal to install the version the project is using manually, but when I saw how nicely you made the ruby version work I figured it was worth considering to make this super simple to use in a nearly drop in and run way for many projects.

Either way, thanks so much for this Action!

[ioquatix]

It's a great idea. Maybe bundler should just be able to do that, e.g. bundler install --locked-version or something.

[dentarg]

I think the plan at ruby/rubygems#3073 (comment) is related to this issue. I'm not sure how far away that is from happening, so I guess this would be great to have until then.

Not sure how tricky this idea is, as written in the README here, Ruby >= 2.6 comes with Bundler installed.

[eregon]

Interesting idea indeed.
I guess the main case where the installed version of Bundler is not enough is for Gemfile.lock with BUNDLE WITH 2.x.y.

Bundler 2 can handle Gemfile.lock generated by Bundler 1 nowadays, unfortunately the Bundler Version Selector in RubyGems causes issues with that: ruby/rubygems#3073

As @dentarg mentioned this might improve in new releases of RubyGems and Bundler.
Not sure how likely that RubyGems would be updated on Ruby 2.4/5/6 though.

It's not clear to me what's the right thing to do here. Currently as the README mentions every Ruby built for setup-ruby comes with either the version of Bundler pre-installed with it (Bundler 2 for 2.7, Bundler 1 for 2.6), or Bundler 1 (<= 2.5).
Installing Bundler at runtime can be quite slow, especially on implementations other than MRI.
In general I think it's still best to use the Bundler pre-installed inside the Ruby whenever possible.

A workaround is to remove the BUNDLED WITH section from Gemfile.lock. Then both Bundler 1 and 2 can install that Gemfile.lock.
Unfortunately, when adding a new gem in Gemfile, any bundle install after that would add the BUNDLED WITH again.

Given all this, I would lean toward adding this feature, but disabled by default, so there would be a new input like install-bundler-from-gemfile-lock: true. We also need to think what would happen if/when this gets fixed in RubyGems and Bundler (i.e. Bundler 1/2 can install a Gemfile.lock 2/1).

[eregon]

Also Bundler and RubyGems were merged recently, which might mean (I'm not sure) there might just be a single Bundler version for a given Ruby installation. In that case we wouldn't be able to gem install bundler:1.x.y, but OTOH that shipped Bundler would likely handle older Gemfile.lock gracefully.

[JPrevost]

I just read up on the discussion linked above and feel like this Action should probably wait for upstream solutions. Thanks for considering the idea and the great discussion.

As a user of this Action, I have easy solutions as is: use the version included with the ruby version or install my own.

Thanks! (I'm happy to close this but as others 👍 I'm hesitant to do that, but I'd fully support it being closed after better understanding the situation).

[rromanchuk]

@JPrevost have you found a reasonable solution to get bundler 2.1.4 installed, even if brute forced, but properly cached? I would prefer CI bundles with the same version as production deployment.

[JPrevost]

@rromanchuk not really, but installing only takes a few seconds on average so I've mostly convinced myself to let it go

[eregon]

I think caching the installation is not really feasible by this action (except one version when building Ruby). As @JPrevost says, at least on Linux/macOS for MRI installing Bundler should be just a couple seconds.

I would prefer CI bundles with the same version as production deployment.

If the Gemfile.lock exists, I would think it's fine to use any version of Bundler with the same major version as BUNDLED WITH. I don't think there is much logic there, just install every gem listed in the Gemfile.lock.

[eregon]

Bundler with the same major version as BUNDLED WITH

Maybe that's actually a simple resolution for this issue: ensure there is a pre-installed Bundler 1 and a Bundler 2 for every Ruby version >= 2.3 (Bundler 2 drops support for Ruby < 2.3). Then it should work to install from any Gemfile.lock. Thoughts?

[JPrevost]

Ironically, this conversation made me look at what we actually use in production rather than what I assumed we were using in production. We deploy on Heroku and they seem to drop the BUNDLED WITH and just use 2.0.2... so I think I'll just update my local version to match my prod version which will have the side effect of making me not have to install it for CI as it's the version the comes with Ruby. 🍻

[eregon]

Yes, BUNDLED WITH isn't strict, it accepts any Bundler with the same major version AFAIK (that was the original intent of the Bundler version autoswitcher feature in RubyGems AFAIK).

[eregon]

Since https://github.com/ruby/setup-ruby/releases/tag/v1.28.0 Bundler will be installed by setup-ruby, so we'll have more flexibility.
I'm thinking to add a new input bundler: ... input which could be a major version (1 or 2 or latest) or Gemfile.lock to read from it.

For the default I'm not sure yet.
Maybe try Gemfile.lock if it exists and has a BUNDLED WITH section,
otherwise default to latest Bundler compatible with the Ruby version (Bundler 2 for Ruby >= 2.3, Bundler 1 for Ruby <= 2.2).

[JPrevost]

For default I personally like checking BUNDLED WITH and using a compatible version. It feels similar to what Heroku is doing from how I understand it and would address my initial reason for filing this Issue.

I was using ruby 2.6.5 and a 2.x version of bundler but this Action only had a 1.x version available because that's what is included in stdlib.

[MSP-Greg]

@eregon

LGTM.

I'm thinking to add a new input bundler:

Add that, and RubyGems might be next. I'd say just look at the Gemfile...