This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Fix loadError occurring in nested bundle exec calls #6689
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
segiddins
approved these changes
Sep 10, 2018
|
Just so it's not forgotten on a slack comment. I think the spec added here passes without the fix? |
9c1a26a to
0676955
Compare
|
I have amended the spec to correctly test this behavior. |
|
@bundlerbot r+ |
|
📌 Commit 0676955 has been approved by |
bundlerbot
added a commit
that referenced
this pull request
Sep 13, 2018
…wandale
Fix loadError occurring in nested bundle exec calls
### What was the end-user problem that led to this PR?
There is a LoadError occurring in Bundler when an application has its Gemfile installed with `--path`, and the user has a recent version of RubyGems that installs a version of Bundler as a default gem.
If the user has some code that they're running with `bundle exec` (like a test suite) that is shelling out and executing `bundle exec` again, the user will receive an error saying that Bundler could not be loaded.
/home/travis/.rvm/gems/ruby-2.5.1/bin/bundle:23:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/exe/bundle (LoadError)
The problem that's happening is that when we run `bundle exec`, Bundler will set the Ruby environment to add the path of the current version of Bundler into the `LOAD_PATH` and also require `bundler/setup`.
RUBYOPT=-rbundler/setup
RUBYLIB=/usr/local/bundle/gems/bundler-1.16.4/lib
This will have Ruby load the lib directory of the version of Bundler the user installed, but it's been loaded with the Gemspec from the default gem version of Bundler that RubyGems installed.
This gemspec is being loaded because RubyGems has a copy of the Bundler gemspec sitting in the default gems. And because we changed `GEM_HOME` when the user ran Bundler with `bundle install --path`, RubyGems just figures that seeing this is only Bundler gemspec it can find, then it should activate it but then `RUBYLIB` comes into play and just overrules RubyGems to load the newer Bundler src.
This is ultimately what's giving us the weird load path that doesn't exist.
### What was your diagnosis of the problem?
See #6537 and #6629
### What is your fix for the problem, implemented in this PR?
When we set the `BUNDLE_BIN_PATH` env var inside bundler, check that the file exists. If it doesn't, we will just set it to the bundle executable file.
### Why did you choose this fix out of the possible options?
This seems to be the solution that patches the LoadError issue without having to heavily refactor code or make the existing code more complicated.
colby-swandale
pushed a commit
that referenced
this pull request
Sep 13, 2018
…wandale
Fix loadError occurring in nested bundle exec calls
### What was the end-user problem that led to this PR?
There is a LoadError occurring in Bundler when an application has its Gemfile installed with `--path`, and the user has a recent version of RubyGems that installs a version of Bundler as a default gem.
If the user has some code that they're running with `bundle exec` (like a test suite) that is shelling out and executing `bundle exec` again, the user will receive an error saying that Bundler could not be loaded.
/home/travis/.rvm/gems/ruby-2.5.1/bin/bundle:23:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/exe/bundle (LoadError)
The problem that's happening is that when we run `bundle exec`, Bundler will set the Ruby environment to add the path of the current version of Bundler into the `LOAD_PATH` and also require `bundler/setup`.
RUBYOPT=-rbundler/setup
RUBYLIB=/usr/local/bundle/gems/bundler-1.16.4/lib
This will have Ruby load the lib directory of the version of Bundler the user installed, but it's been loaded with the Gemspec from the default gem version of Bundler that RubyGems installed.
This gemspec is being loaded because RubyGems has a copy of the Bundler gemspec sitting in the default gems. And because we changed `GEM_HOME` when the user ran Bundler with `bundle install --path`, RubyGems just figures that seeing this is only Bundler gemspec it can find, then it should activate it but then `RUBYLIB` comes into play and just overrules RubyGems to load the newer Bundler src.
This is ultimately what's giving us the weird load path that doesn't exist.
### What was your diagnosis of the problem?
See #6537 and #6629
### What is your fix for the problem, implemented in this PR?
When we set the `BUNDLE_BIN_PATH` env var inside bundler, check that the file exists. If it doesn't, we will just set it to the bundle executable file.
### Why did you choose this fix out of the possible options?
This seems to be the solution that patches the LoadError issue without having to heavily refactor code or make the existing code more complicated.
(cherry picked from commit 8c31a61)
|
☀️ Test successful - status-travis |
colby-swandale
pushed a commit
that referenced
this pull request
Sep 14, 2018
…wandale
Fix loadError occurring in nested bundle exec calls
### What was the end-user problem that led to this PR?
There is a LoadError occurring in Bundler when an application has its Gemfile installed with `--path`, and the user has a recent version of RubyGems that installs a version of Bundler as a default gem.
If the user has some code that they're running with `bundle exec` (like a test suite) that is shelling out and executing `bundle exec` again, the user will receive an error saying that Bundler could not be loaded.
/home/travis/.rvm/gems/ruby-2.5.1/bin/bundle:23:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/exe/bundle (LoadError)
The problem that's happening is that when we run `bundle exec`, Bundler will set the Ruby environment to add the path of the current version of Bundler into the `LOAD_PATH` and also require `bundler/setup`.
RUBYOPT=-rbundler/setup
RUBYLIB=/usr/local/bundle/gems/bundler-1.16.4/lib
This will have Ruby load the lib directory of the version of Bundler the user installed, but it's been loaded with the Gemspec from the default gem version of Bundler that RubyGems installed.
This gemspec is being loaded because RubyGems has a copy of the Bundler gemspec sitting in the default gems. And because we changed `GEM_HOME` when the user ran Bundler with `bundle install --path`, RubyGems just figures that seeing this is only Bundler gemspec it can find, then it should activate it but then `RUBYLIB` comes into play and just overrules RubyGems to load the newer Bundler src.
This is ultimately what's giving us the weird load path that doesn't exist.
### What was your diagnosis of the problem?
See #6537 and #6629
### What is your fix for the problem, implemented in this PR?
When we set the `BUNDLE_BIN_PATH` env var inside bundler, check that the file exists. If it doesn't, we will just set it to the bundle executable file.
### Why did you choose this fix out of the possible options?
This seems to be the solution that patches the LoadError issue without having to heavily refactor code or make the existing code more complicated.
(cherry picked from commit 8c31a61)
colby-swandale
added a commit
that referenced
this pull request
Sep 18, 2018
* 1-16-stable: Version 1.16.5 with changelog scope TruffleRuby platform specs to be RubyGems >= 2.1.0 Auto merge of #6689 - bundler:colby/fix-bundler-load-error, r=colby-swandale Auto merge of #6695 - bundler:segiddins/6684-gvp-prefer-non-pres, r=colby-swandale Auto merge of #6693 - eregon:truffleruby, r=colby-swandale Auto merge of #6692 - eregon:simplify-autoload-require-deprecate, r=segiddins Auto merge of #6688 - voxik:check-search, r=colby-swandale Auto merge of #6682 - bundler:bundle_env_formatting, r=colby-swandale Auto merge of #6675 - MaxLap:master, r=greysteil Auto merge of #6669 - ChrisBr:fix_dep_proxy, r=segiddins Auto merge of #6664 - greysteil:avoid-printing-git-error, r=colby-swandale
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was the end-user problem that led to this PR?
There is a LoadError occurring in Bundler when an application has its Gemfile installed with
--path, and the user has a recent version of RubyGems that installs a version of Bundler as a default gem.If the user has some code that they're running with
bundle exec(like a test suite) that is shelling out and executingbundle execagain, the user will receive an error saying that Bundler could not be loaded.The problem that's happening is that when we run
bundle exec, Bundler will set the Ruby environment to add the path of the current version of Bundler into theLOAD_PATHand also requirebundler/setup.This will have Ruby load the lib directory of the version of Bundler the user installed, but it's been loaded with the Gemspec from the default gem version of Bundler that RubyGems installed.
This gemspec is being loaded because RubyGems has a copy of the Bundler gemspec sitting in the default gems. And because we changed
GEM_HOMEwhen the user ran Bundler withbundle install --path, RubyGems just figures that seeing this is only Bundler gemspec it can find, then it should activate it but thenRUBYLIBcomes into play and just overrules RubyGems to load the newer Bundler src.This is ultimately what's giving us the weird load path that doesn't exist.
What was your diagnosis of the problem?
See #6537 and #6629
What is your fix for the problem, implemented in this PR?
When we set the
BUNDLE_BIN_PATHenv var inside bundler, check that the file exists. If it doesn't, we will just set it to the bundle executable file.Why did you choose this fix out of the possible options?
This seems to be the solution that patches the LoadError issue without having to heavily refactor code or make the existing code more complicated.