This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Could not find 'bundler' #4592
Labels
Comments
|
What is the output of |
|
I have the same issue on arch-linux with the following:
ruby versions tested: Bundler versions gem env: I've narrowed down point where the issue is introduced to #4298. Whether the problem is with bundler or with the way guard uses it I'm not yet sure. |
|
I have created a minimal repo that demonstrates when the issue occurs for me: https://github.com/biinari/bundler-rbenv-guard-issue Included outputs from |
|
I think I've diagnosed this. It's a lot, so I may be missing stuff. In 1.12.5 (and prior 1.12 versions), Inside That drills down into this call stack: ...ending at this bit of code: def configure_gem_home_and_path
blank_home = ENV["GEM_HOME"].nil? || ENV["GEM_HOME"].empty?
if settings[:disable_shared_gems]
ENV["GEM_PATH"] = ""
elsif blank_home || Bundler.rubygems.gem_dir != bundle_path.to_s
possibles = [Bundler.rubygems.gem_dir, Bundler.rubygems.gem_path]
paths = possibles.flatten.compact.uniq.reject(&:empty?)
ENV["GEM_PATH"] = paths.join(File::PATH_SEPARATOR)
end
configure_gem_home
bundle_path
endSince Once we jump over to the new process, we hit this initial code and no matching specs are found, because when @path = split_gem_path env["GEM_PATH"], @home def split_gem_path gpaths, home
# FIX: it should be [home, *path], not [*path, home]
gem_path = []
if gpaths
gem_path = gpaths.split(Gem.path_separator)
# Handle the path_separator being set to a regexp, which will cause
# end_with? to error
if gpaths =~ /#{Gem.path_separator}\z/
gem_path += default_path
end
if File::ALT_SEPARATOR then
gem_path.map! do |this_path|
this_path.gsub File::ALT_SEPARATOR, File::SEPARATOR
end
end
gem_path << home
else
gem_path = default_path
end
gem_path.uniq
endIf Since kernel_load hits up |
|
changing that code to be if settings[:disable_shared_gems]
ENV["GEM_PATH"] = nil # <= ... |
|
@chrismo a PR changing to to |
|
I ran it locally, and got mixed results on specs, but then again I don't think I've run the whole suite locally recently, so I'll push up a PR in a bit. |
chrismo
added a commit
to chrismo/bundler
that referenced
this issue
Jun 22, 2016
Pushing this to get a good build against it to see what side-effects this may cause. It appears to fix rubygems#4592, but the line of code in question goes back to 2010. Issue rubygems#4592 has full write-up on the diagnosis of the problem - if this passes the build, then it should get a spec on it, etc. and a better commit message perhaps.
chrismo
added a commit
to chrismo/bundler
that referenced
this issue
Jun 23, 2016
This should fix rubygems#4592, the tests all pass, but the line of code in question goes back to 2010, so this sorta seems slightly dangerous, but it's probable the circumstances of hitting this line in conjunction with `bundle exec` is a combination that didn't exist prior to 1.12.x. Issue rubygems#4592 has a full diagnosis, but the gist of it is this: if an empty string is passed as the `GEM_PATH` to the subsequent process launched by `bundle exec`, then if the `cmd` portion of `bundle exec` is a ruby shebanged file, then if the current bundle install uses a local path (`disable_shared_gems` is true) then it won't be able to find the bundler gem at all because Bundler doesn't install itself into its own Bundle, it's only installed in the system gems for the Ruby. `nil` must be passed because the RubyGems code that sets up the `GEM_PATH` does a conditional on the current `GEM_PATH` and empty string evaluates to true, whereas `nil` evaluates to false. In the false case the `GEM_PATH` is internally populated with the system gems path such that the bundler gem can be found.
|
First shot tests passing, just pushed up a legit commit with a small method extract and a spec to match. We'll check on it mañana. |
homu
added a commit
that referenced
this issue
Jun 23, 2016
…iddins Unset GEM_PATH with nil not empty string. This should fix #4592, the tests all pass, but the line of code in question goes back to 2010, so this sorta seems slightly dangerous, but it's probable the circumstances of hitting this line in conjunction with `bundle exec` is a combination that didn't exist prior to 1.12.x. Issue #4592 has a full diagnosis, but the gist of it is this: if an empty string is passed as the `GEM_PATH` to the subsequent process launched by `bundle exec`, then if the `cmd` portion of `bundle exec` is a ruby shebanged file, then if the current bundle install uses a local path (`disable_shared_gems` is true) then it won't be able to find the bundler gem at all because Bundler doesn't install itself into its own Bundle, it's only installed in the system gems for the Ruby. `nil` must be passed because the RubyGems code that sets up the `GEM_PATH` does a conditional on the current `GEM_PATH` and empty string evaluates to true, whereas `nil` evaluates to false. In the false case the `GEM_PATH` is internally populated with the system gems path such that the bundler gem can be found.
segiddins
pushed a commit
that referenced
this issue
Jun 27, 2016
…iddins Unset GEM_PATH with nil not empty string. This should fix #4592, the tests all pass, but the line of code in question goes back to 2010, so this sorta seems slightly dangerous, but it's probable the circumstances of hitting this line in conjunction with `bundle exec` is a combination that didn't exist prior to 1.12.x. Issue #4592 has a full diagnosis, but the gist of it is this: if an empty string is passed as the `GEM_PATH` to the subsequent process launched by `bundle exec`, then if the `cmd` portion of `bundle exec` is a ruby shebanged file, then if the current bundle install uses a local path (`disable_shared_gems` is true) then it won't be able to find the bundler gem at all because Bundler doesn't install itself into its own Bundle, it's only installed in the system gems for the Ruby. `nil` must be passed because the RubyGems code that sets up the `GEM_PATH` does a conditional on the current `GEM_PATH` and empty string evaluates to true, whereas `nil` evaluates to false. In the false case the `GEM_PATH` is internally populated with the system gems path such that the bundler gem can be found. (cherry picked from commit 37064b3)
chrismo
added a commit
to chrismo/bundler
that referenced
this issue
Sep 27, 2016
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 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` is 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 patience :)
chrismo
added a commit
to chrismo/bundler
that referenced
this issue
Sep 27, 2016
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 :)
homu
added a commit
that referenced
this issue
Sep 27, 2016
…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.
segiddins
pushed a commit
that referenced
this issue
Sep 30, 2016
…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.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Software
bundle exec gem list|grep guard
bundle exec guard -d
gem env
guard/guard-rspec#369
The text was updated successfully, but these errors were encountered: