This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Regression in disable_shared_gems behavior #4974
Assignees
Labels
Comments
|
I believe this might be intended? I think the idea of disable shared gems is to completely decouple bundler from the set of gems rubygems has |
Yes. But after fix it does not seem to work that way. |
|
Can you share a Gemfile we can use to reproduce the issue? Thanks! |
|
I see this problem with all Gemfiles really. |
|
I cannot produce the issue with the given Gemfile |
|
I am using rbenv. That might be significant. |
|
i can recreate. had to make sure awesome_print was first in my system gems. |
|
I can confirm that 9a8ab67 is the culprit. Since we made that change to accommodate new 1.12 behavior which had broken some The best thing would be to see if a fix can be made to make both cases happy ... but I may not have time to do that in the near future. |
|
|
This was referenced Sep 15, 2016
|
Not terribly cunning actually, just perhaps how this should have been fixed in the first place? #4992 |
|
FWIW, this has caused us to revert to bundler 1.12.5 as well. |
|
@chrismo Thanks for quick fix |
|
The fix is neither quick nor a fix: It doesn't work. See this new comment on the PR #4992. |
|
I think I just run into this issue as well on 1.13.1 . Below is the minimal example, note that |
|
@pibako yes, this looks like the same problem. Presumably you have mime-types, rest-client installed in system gems. Thx for the report, sorry for the trouble. |
|
@chrismo, right, I though I included this in my previous comment: |
|
I cannot reproduce this, but I don't use rbenv |
homu
added a commit
that referenced
this issue
Sep 21, 2016
…ismo Fix GEM_PATH regression in 1.13. This is a bit esoteric. There's two separate pieces to understand first. (1) When `:disable_shared_gems` is true, the `GEM_PATH` gets initialized to an empty string. This is done to make sure it's expanded to ONLY the Bundler --path setting, otherwise it expands to include the system path. (2) Prior to 1.12, the code here in bundle exec didn't use Kernel.load and didn't `require "bundler/setup"`, which meant the path to gems was never involved. In 1.12, bundle exec was overhauled for various reasons to use Kernel.load, and `require "bundler/setup"` is now invoked, which created a bug. 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. We fixed this (the bundle exec bug) in 1.13.0 by changing GEM_PATH to be initialized to nil instead of empty string in all cases. But it created another bug. We've reverted the change so that GEM_PATH is now back to being initialized, but still need to patch up GEM_PATH right here to allow bundle exec to continue to work. Fix #4974 - [x] Needs tests
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.
chrismo
added a commit
that referenced
this issue
Sep 30, 2016
It's more accurate to say what was fixed that was broken. The prior text, "invoking bundler with binstubs generated by RubyGems 2.6.2+" was required to keep what was fixed in 1.13 still fixed.
homu
added a commit
that referenced
this issue
Sep 30, 2016
Change changelog on #4974 It's more accurate to say what was fixed that was broken. The prior text, "invoking bundler with binstubs generated by RubyGems 2.6.2+" was required to keep what was fixed in 1.13 still fixed.
homu
added a commit
that referenced
this issue
Sep 30, 2016
Change changelog on #4974 It's more accurate to say what was fixed that was broken. The prior text, "invoking bundler with binstubs generated by RubyGems 2.6.2+" was required to keep what was fixed in 1.13 still fixed.
ryanfox1985
pushed a commit
to AirRefund/bundler
that referenced
this issue
Oct 4, 2016
* 'master' of github.com:bundler/bundler: (163 commits) remove always-failing 1.8.7 build Rename to force_ruby_platform Fail fast in the specs when running from a path with special characters Change changelog on rubygems#4974 Version 1.13.2 with changelog Auto merge of rubygems#4990 - bundler:seg-realworld-flex, r=segiddins Auto merge of rubygems#4922 - JuanitoFatas:fix/4914-gemfile-engine-symbol-and-string, r=segiddins Auto merge of rubygems#4983 - bundler:seg-redefine-method-visibility, r=indirect Auto merge of rubygems#4994 - bundler:seg-definition-init-perf, r=segiddins Auto merge of rubygems#4971 - bundler:seg-pare-metadata-error, r=indirect Auto merge of rubygems#4998 - srbaker:patch-1, r=segiddins Auto merge of rubygems#4968 - bundler:seg-exec-load-docs, r=indirect Auto merge of rubygems#5002 - alepore:fix-colors, r=indirect Auto merge of rubygems#5015 - m1k3:fix-settings-no-config, r=segiddins Auto merge of rubygems#4992 - chrismo:fix_disable_shared_gems_gem_path, r=chrismo Auto merge of rubygems#5008 - bundler:seg-lazy-specification-materialize-platform, r=indirect Auto merge of rubygems#5014 - bundler:seg-auto-install-bool-key, r=indirect Auto merge of rubygems#4928 - bundler:seg-update-compact-index, r=segiddins Improve IRB behavior in generated bin/console Add a spec for only_ruby_platform ...
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Between the versions
v1.13.0.pre.1andv1.13.0.rc1the behavior ofbundle install --deploymenthas changed concerning thedisable_shared_gemsflag. Gems that are present in system rubygems are no longer installed into the local gems folder (vendor/bundle).This behavior seems to be caused by change in
Bundler#configure_gem_pathofto
introduced in commit 9a8ab67
I tested under 2.4.5.1 rubygems version.
I am sorry If that new behavior is an intended one and not a regression.
The text was updated successfully, but these errors were encountered: