Nested bundle exec support is broken on latest rubygems/bundler combo #4602

SamSaffron · 2016-05-23T06:30:21Z

@indirect asked me to open a new ticket on this: #4381 (comment)

Bundler version: 1.12.4
Rubygems version: 2.6.4

docker exec -it --rm discourse/discourse:1.3.1 /bin/bash
cd /var/www/discourse
discourse@ubuntu-standalone:/var/www/discourse$ bundler --version
Bundler version 1.12.4
discourse@ubuntu-standalone:/var/www/discourse$ gem --version
2.6.4
discourse@ubuntu-standalone:/var/www/discourse$ ruby --version
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]
discourse@ubuntu-standalone:/var/www/discourse$ bundle exec bundle exec ls
bundler: failed to load command: bundle (/usr/local/bin/bundle)
Gem::Exception: can't find executable bundle
  /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.4/lib/bundler/rubygems_integration.rb:373:in `block in replace_bin_path'
  /usr/local/lib/ruby/site_ruby/2.3.0/rubygems.rb:278:in `activate_bin_path'
  /usr/local/bin/bundle:22:in `<top (required)>'

The text was updated successfully, but these errors were encountered:

rubygems/bundler#4602

indirect · 2016-05-23T06:50:24Z

/cc @segiddins

SamSaffron · 2016-05-23T06:53:44Z

Confirmed issue, exact bit by bit same image with rubygems 2.5.1 all is working well and as expected

segiddins · 2016-05-23T18:37:33Z

I'm unable to reproduce this locally, bundle exec bundle exec ls works in all of my projects

indirect · 2016-05-23T18:53:38Z

@segiddins sounds like this might be linux-specific? All the examples I have seen are on Ubuntu.

indirect · 2016-05-23T19:08:49Z

@SamSaffron I need better repro instructions, the commands you gave don't work for me:

$ docker exec -it --rm discourse/discourse:1.3.1 /bin/bash
flag provided but not defined: --rm
See 'docker exec --help'.

segiddins · 2016-05-23T19:21:08Z

I don't have a linux machine, so someone else will have to debug then ¯_(ツ)_/¯

indirect · 2016-05-23T19:21:54Z

I'm perfectly happy to debug in a VM if I can figure out how to repro :P

SamSaffron · 2016-05-24T02:31:20Z

@indirect oops was typing that from memory ... you want

docker run -it --rm discourse/discourse:1.3.1 /bin/bash

% cd /var/www/discourse
% sudo -iEu discourse bundle exec bundle exec ls

rmm5t · 2016-06-02T16:51:23Z

I was able to reproduce the bundle exec bundle exec ls issue, and I just started writing steps to reproduce them in an simple OS X environment (using rbenv).

However, to make the steps completely reproducible, I uninstalled my (rbenv managed) versions of ruby first and then re-installed them from scratch. Afterwards, the problem went away.

Even though I had the latest rubygems and bundler versions prior to the uninstall, I'm not sure what really changed during the reinstall of ruby. Nonetheless, I thought this might be worth mentioning. Reinstalling ruby, rubygems, and bundler in my particular environment made the issue go away. </baffled>

For posterity, here were the steps I took when I was able to reproduce this (even though I can no longer reproduce them after a fresh ruby install):

rbenv shell 2.2.5
gem install bundler --version "~> 1.12.5"
gem update --system
mkdir test-bundler && cd test-bundler
bundle init && bundle install --path vendor && bundle package
bundle exec bundle exec ls

bundler: failed to load command: bundle (/Users/rmcgeary/.rbenv/versions/2.2.5/bin/bundle)
Gem::Exception: can't find executable bundle
  /Users/rmcgeary/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/bundler-1.12.5/lib/bundler/rubygems_integration.rb:373:in `block in replace_bin_path'
  /Users/rmcgeary/.rbenv/versions/2.2.5/lib/ruby/site_ruby/2.2.0/rubygems.rb:278:in `activate_bin_path'
  /Users/rmcgeary/.rbenv/versions/2.2.5/bin/bundle:22:in `<top (required)>'

taonic · 2016-06-03T06:28:22Z

@indirect Have you tried to reproduce the issue from an official ruby docker image? e.g. docker pull ruby:2.3.0-slim I believe the steps described in the original issue can still help to reproduce: #4381 (comment)

Here is the related issue on the docker repo: docker-library/ruby#73

chevinbrown · 2016-06-03T13:42:52Z

+1, I have same issue

mitio · 2016-06-14T09:42:42Z

Some more information on reproducing the issue (on Ubuntu 14.04 LTS x86_64, single Ruby version 2.1.2 installed system-wide under /usr/local/, no Docker).

It turns out that the issue manifests itself only if I've installed/updated Bundler after I've updated Rubygems, not before. Having Bundler 1.12.5 installed on Rubygems 2.6.1 and then updating Rubygems to 2.6.4 seems to work. However, installing Bundler on Rubygems 2.6.4 leads to the issue manifesting itself.

I suspect it might be related to the gem binstubs/shims as gem install bundler on Rubygems 2.6.1 produces a slightly different binstub than the same install command on Rubygems 2.6.4. The only difference between the bundle binstub is the usage of Gem.activate_bin_path in Rubygems 2.6.4 instead of Gem.bin_path in 2.6.1:

- load Gem.bin_path('bundler', 'bundle', version)          # When installed in Rubygems 2.6.1
+ load Gem.activate_bin_path('bundler', 'bundle', version) # When installed in Rubygems 2.6.4

So the Bundler shim with Gem.bin_path still works on Rubygems 2.6.4. That's my workaround for now.

Steps to reproduce on Ubuntu 14.04

Uninstall Bundler, if you have it.
Upgrade Rubygems to 2.6.4.
Install Bundler 1.12.5.
cd to a project with a Gemfile and run bundle exec bundle exec ls.

I can't reproduce it on Mac OS with Ruby via rbenv, though. Might be related to me using rbenv.

Workaround

This is the one-liner I used to revert back to the old Bundler shim, fixing the issue on our servers, without permanently downgrading Rubygems to 2.6.1:

gem uninstall bundler bundle rubygems-update --all -x && \
  gem update --system 2.6.1 && \
  gem install bundler && \
  gem uninstall rubygems-update --all -x && \
  gem update --system 2.6.4

Note that Rubygems 2.6.1 is not compatible with gems installed in Rubygems 2.6.4 and gem install will break under 2.6.1 if you already have that gem installed from 2.6.4. Thus the gem uninstall rubygems-update commands above.

cduez · 2016-06-27T10:23:17Z

rubygems 2.6.6 and bundler 1.12.5 here.

After some minor digging i also found that's related to the change on the activate_bin_path.

I have noticed that we can't run bundler inside bundler, eg: bundle exec bundle version when the binstub contains the activate_bin_path.

With a rails project for example, it works because you call the rails binstub in the app folder bin/bundle which is like this :

#!/usr/bin/env ruby
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)
load Gem.bin_path('bundler', 'bundle')

So, just to be clear, the command: bundle exec ./bin/bundle version print the bundler version.

I have setup a docker image to easily reproduce this bug, you just have to pull and run it

$: docker pull cduez/bundler-4602
$: docker run --rm cduez/bundler-4602
Gem::Exception: can't find executable bundle
  /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/rubygems_integration.rb:373:in `block in replace_bin_path'
  /usr/local/lib/ruby/site_ruby/2.3.0/rubygems.rb:298:in `activate_bin_path'
  /usr/local/bin/bundle:22:in `<top (required)>'

Interesting fact, if you rename the Gemfile, it works :) :

$: docker run -it --rm cduez/bundler-4602 bash
root@0cf6c2858174:/code# mv Gemfile Gemfile2
root@0cf6c2858174:/code# bundle exec bundle version
Bundler version 1.12.5

Here's the Gemfile and the Dockerfile used:

Gemfile:

source 'https://rubygems.org'

gem 'ejs'

Dockerfile:

FROM ruby:2.3

RUN mkdir -p /code/.bundle

WORKDIR code

COPY Gemfile /code/Gemfile

RUN bundle install

CMD ["bundle", "exec", "bundle", "version"]

srbry · 2016-07-19T12:41:25Z

Based on the answer above from @mitio I managed to implement a workaround thats a little simpler:

bundle_path=$(which bundle)
sed -i -e "s/activate_bin_path/bin_path/g" $bundle_path

After running that bundle exec bundle version was successful.

shaneog · 2016-08-02T14:52:02Z

OSX 10.11.6
Rubygems: 2.6.6
Bundler 1.12.5

Confirm that the fix by @srbry works for me.

b-ggs · 2016-08-09T00:47:14Z

Can you check if running 1.13.0.rc.1 fixes this? I tried it out on the discourse docker image, and it seems to work fine.

root@d93becc098d1:/var/www/discourse# bundle exec bundle --version
Bundler version 1.13.0.rc.1
root@d93becc098d1:/var/www/discourse# bundle --version
Bundler version 1.13.0.rc.1
root@d93becc098d1:/var/www/discourse# bundle exec bundle exec ls
Brewfile         LICENSE.txt  adminjs    db                         lib        script
CONTRIBUTING.md  Procfile     app        discourse.sublime-project  log        spec
COPYRIGHT.txt    README.md    bin        docs                       packaging  test
Gemfile          Rakefile     config     images                     plugins    vendor
Gemfile.lock     Vagrantfile  config.ru  jsapp                      public
root@d93becc098d1:/var/www/discourse# bundle exec bundle --version
Bundler version 1.13.0.rc.1
root@d93becc098d1:/var/www/discourse#

cduez · 2016-08-12T09:46:54Z

I just builded a docker image from the ruby 2.3 dockerfile but with bundler version 1.13.0.rc.1 and it works fine this time.

johnl · 2016-08-16T19:06:02Z

I'm having this problem with the "official" docker images too so I'm testing with that, but it makes life really difficult due to a weird configuration. It looks like bundler 1.12.7 is installed in /usr/local/lib/ruby/gems/2.3.0 by default but there are loads of env variables that are then set when you use the container yourself that change it's behaviour. Particularly GEM_HOME=/usr/local/bundle

Anyway, with much faffing around I managed to confirm that if I install 1.13.0.rc.1 in the same weird way they install 1.12.7, then it fixes this problem.

But I thought it worth noting that I think part of the problem here is the weird way these images are installing and configuring bundler in the first place.

The combination of bundler 1.12.5 and rubygems 1.6.2 doesn't play well at all when trying to run gems such as foreman where bundler is used to run bundler. Just upgrading to the latest bundler rc doesn't fix it and changing rubygems causes a massive rebuild. Issues: - rubygems/bundler#4402 - rubygems/bundler#4576 - rubygems/bundler#4602 - docker-library/ruby#73 This PR patches bundler to work around the issue as highlighted here and unbreaks everything for me: rubygems/bundler#4602 (comment)

@taoza

tl;dr `--deployment` will copy _all_ gems to the `--path` now and a proper fix is in place for nested bundle execs when `--path` is set and RubyGems >=2.6.2 is being used. Fixes rubygems#4974. There's two problems blended in here. Let's trace the events here from the beginning, shall we? First off, from probably the first versions of Bundler, when `disable_shared_gems` is true, the `GEM_PATH` gets internally overridden and initialized to an empty string. This is done to make sure that later in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path` setting, otherwise it expands to include the system gems path. In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases, and that new code path calls `require "bundler/setup"`. Later, issue rubygems#4592 was filed, showing that in cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. And as it would later be discovered, was not a problem with RubyGems 2.6.1, but was a problem with >=2.6.2 (and older RubyGems it would seem, though those weren't as thoroughly investigated). We fixed rubygems#4592 (see PR rubygems#4701) in 1.13.0 by changing the oooold code initializing `GEM_PATH` to be initialized to `nil` instead of empty string in all `disable_shared_gems` cases. But it created another bug, filed as rubygems#4974, wherein system gems were no longer copied to the `--path` when `disable_shared_gems` was true. In this commit here (rubygems#4992) we've reverted the change so that `GEM_PATH` is now back to being initialized to an empty string instead of `nil`. That fixes rubygems#4974, but regresses rubygems#4592, and we needed a new way to fix it. After a few tortured attempts at this, I ran across issue rubygems#4602, a similar report of nested bundle execs being broken, rubygems#4602 itself an extension of rubygems#4381 reporting the same problem. It brought to light the role the Rubygems version played in the problem. When the `bundler` gem is installed and the wrapper is generated for any gem executables, the contents of this wrapper are determined by the Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of `Gem.bin_path` with its own, and has for a long time made a special exception for the Bundler gem itself, short-circuiting with the contents of a special ENV variable called `BUNDLE_BIN_PATH`. In Rubygems 2.6.2, `bin_path` was superseded by a new `Gem.activate_bin_path` method which did what `bin_path` did but also activated the gem. Bundler 1.13 added support for this, but it didn't include the same short-circuit for bundler itself. (Alert user @taoza even noticed this here rubygems@fcaab35#r56665282). This commit also includes that short circuit for Rubygems >=2.6.2 now and nested bundle exec should continue to work. Thx to @miros for filing rubygems#4974 and isolating the problem in 1.12, @segiddins for many contributions and better ideas, and everyone else for their bug reports and patience :)

@taoza

…ismo Fix GEM_PATH regression in 1.13. _nth time is a charm ... here's the latest latest latest commit message_: Fix disable_shared_gems bug & keep nested exec tl;dr `--deployment` will copy _all_ gems to the `--path` now and a proper fix is in place for nested bundle execs when `--path` is set and RubyGems >=2.6.2 is being used. Fixes #4974. There's two problems blended in here. Let's trace the events here from the beginning, shall we? First off, from probably the first versions of Bundler, when `disable_shared_gems` is true, the `GEM_PATH` gets internally overridden and initialized to an empty string. This is done to make sure that later in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path` setting, otherwise it expands to include the system path. In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases, and that new code path calls `require "bundler/setup"`. Later, issue #4592 was filed, showing that in cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. And as it would later be discovered, was not a problem with RubyGems 2.6.1, but was a problem with >=2.6.2 (and older RubyGems it would seem, though those weren't as thoroughly investigated). We fixed #4592 (see PR #4701) in 1.13.0 by changing the oooold code initializing `GEM_PATH` to be initialized to `nil` instead of empty string in all `disable_shared_gems` cases. But it created another bug, filed as #4974, wherein system gems were no longer copied to the `--path` when `disable_shared_gems` is true. In this commit here (#4992) we've reverted the change so that `GEM_PATH` is now back to being initialized to an empty string instead of `nil`. That fixes #4974, but regresses #4592, and we needed a new way to fix it. After a few tortured attempts at this, I ran across issue #4602, a similar report of nested bundle execs being broken, #4602 itself an extension of #4381 reporting the same problem. It brought to light the role the Rubygems version played in the problem. When the `bundler` gem is installed and the wrapper is generated for any gem executables, the contents of this wrapper are determined by the Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of `Gem.bin_path` with its own, and has for a long time made a special exception for the Bundler gem itself, short-circuiting with the contents of a special ENV variable called `BUNDLE_BIN_PATH`. In Rubygems 2.6.2, `bin_path` was superseded by a new `Gem.activate_bin_path` method which did what `bin_path` did but also activated the gem. Bundler 1.13 added support for this, but it didn't include the same short-circuit for bundler itself. (Alert user @taoza even noticed this here fcaab35#r56665282). This commit also includes that short circuit for Rubygems >=2.6.2 now and nested bundle exec should continue to work.

@taoza

…ismo Fix GEM_PATH regression in 1.13. _nth time is a charm ... here's the latest latest latest commit message_: Fix disable_shared_gems bug & keep nested exec tl;dr `--deployment` will copy _all_ gems to the `--path` now and a proper fix is in place for nested bundle execs when `--path` is set and RubyGems >=2.6.2 is being used. Fixes #4974. There's two problems blended in here. Let's trace the events here from the beginning, shall we? First off, from probably the first versions of Bundler, when `disable_shared_gems` is true, the `GEM_PATH` gets internally overridden and initialized to an empty string. This is done to make sure that later in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path` setting, otherwise it expands to include the system path. In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases, and that new code path calls `require "bundler/setup"`. Later, issue #4592 was filed, showing that in cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. And as it would later be discovered, was not a problem with RubyGems 2.6.1, but was a problem with >=2.6.2 (and older RubyGems it would seem, though those weren't as thoroughly investigated). We fixed #4592 (see PR #4701) in 1.13.0 by changing the oooold code initializing `GEM_PATH` to be initialized to `nil` instead of empty string in all `disable_shared_gems` cases. But it created another bug, filed as #4974, wherein system gems were no longer copied to the `--path` when `disable_shared_gems` is true. In this commit here (#4992) we've reverted the change so that `GEM_PATH` is now back to being initialized to an empty string instead of `nil`. That fixes #4974, but regresses #4592, and we needed a new way to fix it. After a few tortured attempts at this, I ran across issue #4602, a similar report of nested bundle execs being broken, #4602 itself an extension of #4381 reporting the same problem. It brought to light the role the Rubygems version played in the problem. When the `bundler` gem is installed and the wrapper is generated for any gem executables, the contents of this wrapper are determined by the Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of `Gem.bin_path` with its own, and has for a long time made a special exception for the Bundler gem itself, short-circuiting with the contents of a special ENV variable called `BUNDLE_BIN_PATH`. In Rubygems 2.6.2, `bin_path` was superseded by a new `Gem.activate_bin_path` method which did what `bin_path` did but also activated the gem. Bundler 1.13 added support for this, but it didn't include the same short-circuit for bundler itself. (Alert user @taoza even noticed this here fcaab35#r56665282). This commit also includes that short circuit for Rubygems >=2.6.2 now and nested bundle exec should continue to work.

chrismo · 2016-10-03T05:02:05Z

1.13.2 is out now and this should still be fixed, but the 1.13.0 fix was reverted so as to solve #4992 and replaced with a better fix. Possibly we can close this now? But it's a long issue with many participants, so if there's a case here I'm overlooking (which could easily be true), please chime in!

MatzFan · 2016-10-03T17:26:58Z

FWIW I think I experienced a version of this issue running Homebrew's brew tests command (which does system "bundle", "exec", "parallel_test", .... from a Ruby file) locally with RG 2.6.4 & bundler 1.13.2 (RVM 1.27.0, Ruby 2.3.1 & OSX 10.11.6). Good news is running @mitio's one-liner fixed it (many thanks!) . I've included the error below in case others seeing something similar are directed here like I was via Google 😄 .

/Users/me/.rvm/gems/ruby-2.3.1/bin/bundle:22:in `<main>': undefined method `activate_bin_path' for Gem:Module (NoMethodError)
    from /Users/me/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `eval'
    from /Users/me/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `<main>'
/Users/me/.rvm/gems/ruby-2.3.1/bin/bundle:22:in `<main>': undefined method `activate_bin_path' for Gem:Module (NoMethodError)
    from /Users/me/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `eval'
    from /Users/me/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `<main>'

bfad · 2016-10-06T19:42:23Z

I recently updated to 1.13.2 and ran into this issue. I uninstalled bundler and then installed 1.12.5 to get things working again. This was with Ruby 2.1.6 and Ruby Gems 2.2.3

julik · 2016-10-12T10:24:15Z

Is there any hint of a solution that allows the latest Bunder to be combined with the latest Rubygems, or is this still in limbo?

nickhoffman · 2016-11-03T13:45:04Z

This looks like a duplicate of #4402, or at least very similar.

chrismo · 2016-11-04T19:40:27Z

I think there's two issues afoot here. One is a bundler bug (see #4992) involving disable_shared_gems - that was also probably influenced by the version of RG in use. This is the original issue here.

The other problem, as seen in @MatzFan's comment above, is undefined method 'activate_bin_path' - that's not the same issue as the original issue, though is due to issues surrounding the generated binstubs/shims before and after the introduction of activate_bin_path in RG 2.6.2? (maybe 2.6.4).

We should probably make a new issue for the latter item here and close out this one (4602). I'm going to do some more research on the shims issue first.

chrismo · 2016-11-04T19:41:25Z

@bfad and @julik can you specify which symptom/problem you are experiencing, since the issue (see my prior comment) appears to have 2 separate problems.

bfad · 2016-11-04T21:49:05Z

@chrismo I'm pretty sure my issue is the disable_shared_gems issue as I have that set to true and the error I'm getting is Gem::LoadError. Again, this is under 1.13.2 and I don't see the issue under 1.12.5

chrismo · 2016-11-04T22:04:38Z

@bfad ok - I don't see any other mention of Gem::LoadError on this issue. Can you post either bundle env or a reproducible case?

chrismo · 2016-11-04T22:35:59Z

to confirm - the bug fix in #4992 handles this case with RubyGems 2.6.2+ and Bundler 1.12:

=> gem uninstall rubygems-update -a -x --force
=> gem uninstall bundler -a -x --force
Removing bundle
Removing bundler
Successfully uninstalled bundler-1.12.6
=> gem update --system 2.6.2
Updating rubygems-update
Successfully installed rubygems-update-2.6.2
Parsing documentation for rubygems-update-2.6.2
Installing ri documentation for rubygems-update-2.6.2
Installing darkfish documentation for rubygems-update-2.6.2
Done installing documentation for rubygems-update after 3 seconds
Parsing documentation for rubygems-update-2.6.2
Done installing documentation for rubygems-update after 0 seconds
Installing RubyGems 2.6.2
RubyGems 2.6.2 installed
Parsing documentation for rubygems-2.6.2
Installing ri documentation for rubygems-2.6.2
...
RubyGems system software updated
=> gem install bundler -v 1.12.6
Successfully installed bundler-1.12.6
Parsing documentation for bundler-1.12.6
Installing ri documentation for bundler-1.12.6
Done installing documentation for bundler after 5 seconds
1 gem installed
=> bundle exec bundle exec ls
bundler: failed to load command: bundle (/Users/chrismo/dev/bundler-cases/zz/ruby/2.3.0/bin/bundle)
Gem::Exception: can't find executable bundle
  /Users/chrismo/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.12.6/lib/bundler/rubygems_integration.rb:373:in `block in replace_bin_path'
  /Users/chrismo/.rbenv/versions/2.3.1/lib/ruby/site_ruby/2.3.0/rubygems.rb:278:in `activate_bin_path'
  /Users/chrismo/dev/bundler-cases/zz/ruby/2.3.0/bin/bundle:22:in `<top (required)>'

the other, similar symptom, but not #4992 is with RubyGems 2.6.1 and Bundler 1.12:

=> gem uninstall rubygems-update -a -x --force
Removing update_rubygems
Successfully uninstalled rubygems-update-2.6.2
=> gem uninstall bundler -a -x --force
Successfully uninstalled bundler-1.12.6
Removing bundle
Removing bundler
Successfully uninstalled bundler-1.13.6
=> gem update --system 2.6.1
Updating rubygems-update
Successfully installed rubygems-update-2.6.1
Parsing documentation for rubygems-update-2.6.1
Installing ri documentation for rubygems-update-2.6.1
Installing darkfish documentation for rubygems-update-2.6.1
Done installing documentation for rubygems-update after 2 seconds
Parsing documentation for rubygems-update-2.6.1
Done installing documentation for rubygems-update after 0 seconds
Installing RubyGems 2.6.1
RubyGems 2.6.1 installed
Parsing documentation for rubygems-2.6.1
Installing ri documentation for rubygems-2.6.1
...
RubyGems system software updated
=> gem install bundler -v 1.12.6
Successfully installed bundler-1.12.6
Parsing documentation for bundler-1.12.6
Installing ri documentation for bundler-1.12.6
Done installing documentation for bundler after 6 seconds
1 gem installed
=> bundle exec bundle exec ls
bundler: failed to load command: bundle (/Users/chrismo/dev/bundler-cases/zz/ruby/2.3.0/bin/bundle)
NoMethodError: undefined method `activate_bin_path' for Gem:Module
  /Users/chrismo/dev/bundler-cases/zz/ruby/2.3.0/bin/bundle:22:in `<top (required)>'

I need to find if there's a RG case for this latter problem.

Neither of these cases occur for me with 1.13. Those of you with 1.13 problems similar to these, if you offer up some steps to reproduce I'll take a look.

bfad · 2016-11-05T14:22:52Z

@chrismo First, #4992 says it fixes it for 1.13, not 1.12. Also, bundler 1.12.5 is working fine for me, it's 1.13.2 that I reported that I had a problem with nested bundle execs. I also had the problem with 1.13.6 (the latest version). All of this was for Ruby 2.1.6 and Ruby Gems 2.2.3.

Based on your suggestions above, I ran these commands to update my version of Ruby Gems and re-install bundler:

$> gem uninstall rubygems-update -a -x --force
$> gem uninstall bundler -a -x --force
$> gem update --system
$> gem install bundler

This gave me Ruby Gem version 2.6.8 and Bundler version 1.13.6 and fixed my issue. Thank you so much for the pointer to update my Ruby Gems version. I hope this helps other people too.

krin-san · 2016-11-17T10:37:11Z

I have the following setup: bundler + fastlane + danger. The fastlane lane declares all required variables to simulate Xcode Server CI environment with a PR number for danger and to declare credentials to a BitbucketServer.

In a forked Bundler repo I enabled BitbucketServer support for XcodeServerCI.

Gemfile

# frozen_string_literal: true
source "https://rubygems.org"

gem 'cocoapods', '1.1.1'
gem 'fastlane', '~> 1.107.0'
# DangerCI
gem 'danger', '4.0.1', :git => 'https://github.com/krin-san/danger.git'
gem 'xcpretty', '~> 0.2.4' # Dependency for 'danger-xcode_summary'
gem 'xcpretty-json-formatter', '>= 0.1.0' # Dependency for 'danger-xcode_summary'
gem 'danger-xcode_summary'

Fastfile

    lane :pull_request do
        ENV['XCS_BOT_NAME'] = 'BuildaBot [Project/repo_name] PR #41'
        ENV['XCS_ERROR_COUNT'] = '0'
        ENV['XCS_TEST_FAILURE_COUNT'] = '0'

        ENV['DANGER_BITBUCKETSERVER_HOST'] = 'bitbucket-server.company.com'
        ENV['DANGER_BITBUCKETSERVER_USERNAME'] = 'username'
        ENV['DANGER_BITBUCKETSERVER_PASSWORD'] = 'password'

        sh("cd .. && bundle exec danger --verbose")
    end

@bfad, I tried your solution and have the same rubygems and Bundler versions you have. The direct call to danger with all env variables works ok:

XCS_BOT_NAME='BuildaBot [Project/repo_name] PR #41' XCS_ERROR_COUNT='0' XCS_TEST_FAILURE_COUNT='0' DANGER_BITBUCKETSERVER_HOST='bitbucket-server.company.com' DANGER_BITBUCKETSERVER_USERNAME='username' DANGER_BITBUCKETSERVER_PASSWORD='password' bundle exec danger --verbose

but when I try to call it via pull_request lane with bundle exec fastlane ios pull_request it fails on the next lines in danger.rb:25:

  # @return [String] The path to the local gem directory
  def self.gem_path
    if Gem::Specification.find_all_by_name(GEM_NAME).empty? # Empty array returned here
      raise "Couldn't find gem directory for 'danger'"
    end
    return Gem::Specification.find_by_name(GEM_NAME).gem_dir
  end

Error log

bundler: failed to load command: danger (/Library/Ruby/Gems/2.0.0/bin/danger)
Gem::MissingSpecError: Could not find 'danger' (>= 0) among 138 total gem(s)
Checked in 'GEM_PATH=/Library/Ruby/Gems/2.0.0:/Users/local_dev/.gem/ruby/2.0.0:/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/gems/2.0.0', execute `gem env` for more information
  /Library/Ruby/Site/2.0.0/rubygems/dependency.rb:308:in `to_specs'
  /Library/Ruby/Site/2.0.0/rubygems/dependency.rb:320:in `to_spec'
  /Library/Ruby/Site/2.0.0/rubygems/specification.rb:1028:in `find_by_name'
  /Users/local_dev/.bundle/ruby/2.0.0/danger-c40f4a46aab9/lib/danger.rb:26:in `gem_path'
  /Users/local_dev/.bundle/ruby/2.0.0/danger-c40f4a46aab9/lib/danger/helpers/comments_helper.rb:97:in `apply_template'

indirect · 2016-11-17T21:03:03Z

@krin-san thank you for reporting this! unfortunately your post doesn't contain enough information for us to reproduce the problem. Please check ISSUES and open a new ticket with a list of steps that anyone can follow to recreate the problem. Thanks!

krin-san · 2016-11-18T07:45:01Z

@indirect, Ok, I'll try to make a demo repo with this issue reproducible.

chrismo · 2016-12-19T05:19:19Z

@krin-san if you do go back to this - let's open a new ticket, I think this one has done its duty, and it your symptom doesn't appear to be entirely the same.

krin-san · 2016-12-19T20:26:25Z

@chrismo, I tried to make a clean setup to reproduce the bug above but I can't. Not sure, maybe I had something locally that breaks normal behavior.
Anyway thanks for notyfing!

…ecific order as mentioned in [rubygems/bundler#4602 (comment)]. This solved the problem to: [$ bundle exec bundle version —> /rubygems.rb `find_spec_for_exe': can't find gem bundler (>= 0.a) (Gem::GemNotFoundException)]

roberthopman · 2017-11-13T12:05:16Z

I tried a couple of the above solutions and none solved the problem. I have x_test.rb with x.rb and want to use guard-minitest. I added a GEMFILE and ran bundle install with the

source 'http://rubygems.org'

gem 'guard-minitest'

Now I get a similar error message when i run bundle exec guard init minitest:

bundler/rubygems_integration.rb:458:in `block in replace_bin_path': can't find executable guard for gem guard. guard is not currently included in the bundle, perhaps you meant to add it to your Gemfile? (Gem::Exception)
	from /Users/robert/.rvm/rubies/ruby-2.2.6/lib/ruby/site_ruby/2.2.0/bundler/rubygems_integration.rb:478:in `block in replace_bin_path'
	from /Users/robert/.rvm/gems/ruby-2.2.6/bin/guard:22:in `<main>'
	from /Users/robert/.rvm/gems/ruby-2.2.6/bin/ruby_executable_hooks:15:in `eval'
	from /Users/robert/.rvm/gems/ruby-2.2.6/bin/ruby_executable_hooks:15:in `<main>'

Please advise. Answer: https://github.com/guard/guard-minitest#install

SamSaffron added a commit to discourse/discourse_docker that referenced this issue May 23, 2016

latest rubygems has problems

2f36b7c

rubygems/bundler#4602

segiddins added the type: bug report label May 23, 2016

b-ggs mentioned this issue Jun 2, 2016

Boggs - 6/2/2016 RochesterinNYC/bundler-gsoc#17

Closed

coilysiren added the status: working label Jun 2, 2016

This was referenced Jun 2, 2016

rubygems 2.6.2 breaks nested bundle exec support #4381

Closed

bundler error when spring: true is combined with bundler v1.12 in Rails 4.2 environment guard/guard-minitest#139

Closed

sckott mentioned this issue Jun 18, 2016

installation trouble sckott/extcite#4

Closed

glennpratt mentioned this issue Jun 20, 2016

Gem::Exception: can't find executable #4576

Closed

b-ggs mentioned this issue Aug 2, 2016

Boggs - 8/2/2016 RochesterinNYC/bundler-gsoc#49

Closed

phyrog mentioned this issue Aug 12, 2016

Broken travis builds ontohub/ontohub#1781

Closed

johnl mentioned this issue Aug 16, 2016

Nested bundler is broken docker-library/ruby#82

Closed

chrismo mentioned this issue Sep 27, 2016

Fix GEM_PATH regression in 1.13. #4992

Merged

chrismo mentioned this issue Nov 4, 2016

Double exec failure under weird circumstances #4402

Closed

chrismo added the status: user feedback required label Dec 18, 2016

chrismo closed this as completed Dec 19, 2016

ethagnawl mentioned this issue Jan 24, 2017

Tmuxinator won't start tmuxinator/tmuxinator#500

Closed

mtylty mentioned this issue Mar 14, 2017

Add deploy command nebulab/pulsar#36

Merged

mitsururike mentioned this issue May 30, 2017

update sysutils/rubygem-bundler to 1.15.0 reallyenglish/freebsd-ports#400

Merged

tf mentioned this issue Nov 2, 2017

LoadError when trying to invoke bundle exec from ruby script after bundler/setup #6144

Closed

weiqingtoh mentioned this issue Dec 23, 2017

[URGENT] Travis cannot execute build (Gems cannot load via bundler) Coursemology/coursemology2#2713

Closed

Nested bundle exec support is broken on latest rubygems/bundler combo #4602

Nested bundle exec support is broken on latest rubygems/bundler combo #4602

Comments

SamSaffron commented May 23, 2016

indirect commented May 23, 2016

SamSaffron commented May 23, 2016

segiddins commented May 23, 2016

indirect commented May 23, 2016

indirect commented May 23, 2016

segiddins commented May 23, 2016

indirect commented May 23, 2016

SamSaffron commented May 24, 2016

rmm5t commented Jun 2, 2016

taonic commented Jun 3, 2016 • edited Loading

chevinbrown commented Jun 3, 2016

mitio commented Jun 14, 2016 • edited Loading

Steps to reproduce on Ubuntu 14.04

Workaround

cduez commented Jun 27, 2016 • edited Loading

srbry commented Jul 19, 2016

shaneog commented Aug 2, 2016

b-ggs commented Aug 9, 2016

cduez commented Aug 12, 2016

johnl commented Aug 16, 2016

chrismo commented Oct 3, 2016

MatzFan commented Oct 3, 2016

bfad commented Oct 6, 2016

julik commented Oct 12, 2016

nickhoffman commented Nov 3, 2016

chrismo commented Nov 4, 2016

chrismo commented Nov 4, 2016

bfad commented Nov 4, 2016 • edited Loading

chrismo commented Nov 4, 2016

chrismo commented Nov 4, 2016 • edited Loading

bfad commented Nov 5, 2016

krin-san commented Nov 17, 2016

indirect commented Nov 17, 2016

krin-san commented Nov 18, 2016

chrismo commented Dec 19, 2016

krin-san commented Dec 19, 2016

roberthopman commented Nov 13, 2017 • edited Loading

taonic commented Jun 3, 2016 •

edited

Loading

mitio commented Jun 14, 2016 •

edited

Loading

cduez commented Jun 27, 2016 •

edited

Loading

bfad commented Nov 4, 2016 •

edited

Loading

chrismo commented Nov 4, 2016 •

edited

Loading

roberthopman commented Nov 13, 2017 •

edited

Loading