Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add flag to generate generic binstubs #6524
What was the end-user problem that led to this PR?
Issues #6154 and #6162, in which Bundler v1.16.1 appeared to be looking for the wrong Gemfile when using Docker. Further investigation showed that this issue was not just limited to the use of Docker (see non-Docker repro of 6154).
What was your diagnosis of the problem?
The diagnosis was that as of 1.16 Bundler started generating a
What is your fix for the problem, implemented in this PR?
My fix was to add a flag to the
Why did you choose this fix out of the possible options?
I chose this fix because of the conversation from #6469.
As some background information, the
binstubs command was created specifically to create binstubs that are locked to a single application.
If you want binstubs that are not locked to the given application, you can currently use the binstubs that are already generated for every Bundle, at
I think I would be okay a flag that caused Bundler to generate additional global binstubs on demand, if you need that for some reason.
Is there something stopping you from using those binstubs that already exist?
From a conversation with @eanlain:
In Ye Olden Times™, anytime you installed gems (with rubygems) you would get rubygems binstubs
then we had the idea to add bundle-specific binstubs, so you could run
it seems like at some point, the docker folks realized that
then we started getting bug reports about binstubs, where sometimes they would NOT load the version of rake specified in the application bundle, because they were being called from a CWD that contained a different gemfile. for example,
that’s when we “fixed the bug” by adding a hardcoded gemfile path to
wow, okay... I now see what you are saying. I am kind of astonished and impressed and horrified. So that configuration will actually cause bundler to create the rubygems binstubs and then overwrite them with bundler-application-specific binstubs.
if you want your binstubs to only work with one application, it’s kind of genius. Someone clearly came up with a clever plan for docker images that only have one application in them, to stop needing bundle exec. Of course, if you do that, you have made it completely impossible for yourself to run any command without bundle exec, which is why bundler doesn’t do that
So if you want binstubs that you can use outside your bundled application, you should unset both of those configs and run
After the discussion, we have tentatively decided to close this PR and resolve the issues discussed via Bundler and Docker configuration instead. Hopefully @eanlain can follow up with what he eventually settles on in his Dockerfile, and we can use that as the basis for a future website page about using Bundler with Docker.
referenced this pull request
Jul 6, 2018
The Dockerfiles that I ran into issues with were explicitly setting
ENV GEM_HOME="/usr/local/bundle" ENV BUNDLE_PATH="$GEM_HOME" ENV BUNDLE_BIN="$GEM_HOME/bin" ENV PATH="$BUNDLE_BIN:$PATH"
The Dockerfiles would then run
The application-locked bundler binstubs were "locked" to the gemfile that was present when running
The fix was to unset
ENV GEM_HOME="/usr/local/bundle" ENV PATH $GEM_HOME/bin:$GEM_HOME/gems/bin:$PATH
It looks like similar changes were made in the docker-library/ruby dockerfiles, see: