Stop setting BUNDLE_PATH

[deivid-rodriguez]

Newer bundler versions install gems to $GEM_HOME/ruby/<ruby_version>, instead of directly to $GEM_HOME.

So we need to add the proper paths to GEM_PATH and PATH so that gems
and their executables are properly found.

This is the proposal to fix rubygems/bundler#7494.

These changes are expected to be fully backwards compatible and should pass all the smoke tests to be added to https://github.com/docker-library/official-images:

• ruby-binstubs: Add some tests for bundler finding binstubs official-images#7166 and maybe Update run.sh to use the latest version of bundler (2.1.2) official-images#7208 or Only test whatever bundler version comes with ruby by default official-images#7229 as a followup.
• ruby-bundler extended to check for "deployment" setups: Add --deployment flag check to ruby-bundler test official-images#7188.

[deivid-rodriguez]

Ok, so I was working on this and I realized removing BUNDLE_PATH might be the better option.

On one hand, it fixes the issue, since it no longer hits the particularly problematic behaviour and restores the previous behaviour.

On the other hand, It's simpler and I think deviating from bundler's default configuration has historically confused users. It's also simpler in docker images to set an environment variable than to unset it, so removing BUNDLE_PATH is more flexible. See for example #297 or #42.

Finally, all bundler versions shipped with all supported rubies install gems to GEM_HOME by default, so this should be backwards compatible and not change any behavior. It looks like this was originally introduced in #21, and intended to fix precisely the issue we're having now (gem list not matching bundle list). In particular, see #42 (comment). But what's explained in that comment should be the default behavior, so maybe the problem back then was a bug in an old bundler version or something like that.

Other bundler configurations meant to avoid the creation of a .bundle folder local to the working directory are preserved, and nothing should change regarding that.

Also, note that the behavior of installing gems globally is expected to change in the future, but it won't happen any time soon, so we'll deal with that when it happens.

[deivid-rodriguez]

Changed the title to reflect the new approach.

[tianon]

LGTM 👍

(Really appreciate the detailed summary and the time spent figuring out the best path forward!! 🤘)

[deivid-rodriguez]

Thanks both for your patience! 💜

[jimeh]

@tianon do you happen know when we might expect to see this change in the images on Docker Hub?

My understanding is a PR must be raised against docker-library/official-images. If there's no plan to do that at the moment, and it's open for anyone to do, I'd be happy to volunteer myself.

[jimbali]

Thanks for all your work on this @deivid-rodriguez! :)

[deivid-rodriguez]

You're welcome! Also thanks @jimeh for the super useful input :)

[jimeh]

@deivid-rodriguez you did all the heavy lifting, I just butted in with annoying questions from time to time :D... thanks for all your effort :)

[slayer]

This PR broke our CI builds :(

[deivid-rodriguez]

I'm sorry that happened @slayer. I wasn't expecting anything to break, but this is not a perfect world as experience keeps proving.

Can you elaborate a bit more what happened? I'm pretty confident this is the right direction to take for the official images, but I'd still like to hear about your situation to see if there's something we should be changing.

[slayer]

It is non critical, I have already fixed our Dockerfile, it just was a surprise when build suddenly fails

We used chown -r ${APP_USER} ${BUNDLE_PATH} to be able setup bundle gems under non-root user.

[deivid-rodriguez]

Oh, I see. So the command became invalid when removing the BUNDLE_PATH environment variable... Yeah, I think this is an acceptable incompatibility that it's better to fix in the end users images like you did, I'm sorry it bit you though.

[NobodysNightmare]

@tianon do you happen know when we might expect to see this change in the images on Docker Hub?

My understanding is a PR must be raised against docker-library/official-images. If there's no plan to do that at the moment, and it's open for anyone to do, I'd be happy to volunteer myself.

So I understand it correct that these changes are not yet live in the official images, are they?

I can still see the issue with ruby:2.6.4-alpine, so now I was wondering, whether I still have a mistake on my side or whether the official images are just not yet updated.

[deivid-rodriguez]

They were updated a while ago.

The issue you're having is that only the latest patch level version of each ruby is officially maintained and receives patches. So in addition to the mentioned workarounds, you could upgrade to ruby-2.6.5.

$ docker run --rm -it ruby:2.6.4-alpine sh -c "echo \$BUNDLE_PATH"
Unable to find image 'ruby:2.6.4-alpine' locally
2.6.4-alpine: Pulling from library/ruby
9d48c3bd43c5: Already exists 
9ce9598067e7: Pull complete 
278f4c997324: Pull complete 
a3a302efd712: Pull complete 
9d45a498a618: Pull complete 
Digest: sha256:f3eeb2b71ae7c004ca57ddb12618fde07dece33e6a0f0a50b53f03b83be76174
Status: Downloaded newer image for ruby:2.6.4-alpine
/usr/local/bundle

$ docker run --rm -it ruby:2.6.5-alpine sh -c "echo \$BUNDLE_PATH"
Unable to find image 'ruby:2.6.5-alpine' locally
2.6.5-alpine: Pulling from library/ruby
c9b1b535fdd9: Pull complete 
68ee169f7fe0: Pull complete 
c0dce75739cf: Pull complete 
8c71c542757d: Pull complete 
93d37870039a: Pull complete 
Digest: sha256:deaf1c8117ad605b45f879a84389afcd3030f302af3c9cffd8f827077882ad4d
Status: Downloaded newer image for ruby:2.6.5-alpine

$