search

joshuaflanagan / serverless-ruby-package

serverless plugin to package ruby gems
39 stars 11 forks source link

Add support for `gems.rb`. #8

Closed Skudo closed 4 years ago

Skudo commented 5 years ago

We use gems.rb (and gems.locked) and as a workaround, passing the BUNDLER_GEMFILE environment variable to the serverless call works for us. However, things would be more of a no-brainer, if serverless-ruby-package could determine the right file by itself.

This PR addresses exactly that issue.

joshuaflanagan commented 5 years ago

Thank you for this contribution!

Can you add a reference to official guidance from bundler that this is a new adopted convention? I hadn't heard of it, and during research, only found references from 3rd party articles suggesting that it may be coming. In the official channels, I only found a closed issues (https://github.com/bundler/bundler/issues/694) and a changelog that does not mention it (https://bundler.io/guides/bundler_2_upgrade.html).

I agree with merging this change, if it is the accepted future behavior of bundler. We already have a mechanism for supporting team-specific conventions (by setting BUNDLER_GEMFILE).

Skudo commented 5 years ago

tl;dr: bundler does support gems.rb, but they've swayed from deprecating Gemfile and in fact, Gemfile still seems to be the default for 2.0.2.

Interestingly, the bundler team went from "We are going to remove Gemfile and Gemfile.lock with bundler 2.0" (citation needed) to "We are going to remove Gemfile and Gemfile.lock with bundler 3.0, showing deprecation warnings with 2.0" to "We will just let Gemfile and Gemfile.lock stick around with no actual plans to remove support for them". The speaker in that video also said gems.rb would have higher precedence over Gemfile, but apparently, bundler does not work that way for me (bundler 2.0.2).

I was made aware that bundler wanted to tackle the issues with the naming of Gemfile and Gemfile.lock by reinforcing the change to gems.rb and gems.locked respectively at EuRuKo 2016, iirc, and since the bundler team added support for gems.rb soon after, I have been assuming that the days of Gemfile were numbered. It seems like I've been wrong for at least two years now.

Thanks a lot for requesting some reference on the supposed move to gems.rb. Otherwise, I wouldn't have learnt about the change in policy.

Knowing all that, I would still argue that this PR is not entirely invalid. However, I am perfectly fine with not accepting this PR based on the fact that you have to actively deviate from the still common standard Gemfile practice in order to have your project use bundler with gems.rb. After all, serverless-ruby-package respects the BUNDLE_GEMFILE environment variable, which in my opinion is an acceptable workaround for people going the gems.rb path.