This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
"cannot load such file" @bundler 1.16.2 with old ruby version. #6537
Labels
Comments
|
We see the same issue with Ruby 2.3.0: |
|
I've seen something similar on a client using CircleCI parallel builds: This is with Docker and Ruby 2.3.7. Reverting to Bundler 1.16.1 fixes the issue. Partial CircleCI setup for the record: version: 2
jobs:
build:
docker:
# https://circleci.com/docs/2.0/circleci-images/#ruby
# NOTE: stretch refers to the current "Debian" stable
- image: circleci/ruby:2.3.7-stretch
parallelism: 2
steps:
- checkout
# some code uses the "look" command
- run: sudo apt-get install bsdmainutils
# Covers against CVEs in rubygems
- run: gem update --system
# We're meeting failures with 1.16.2 on CircleCI
- run: gem install bundler --version 1.16.1
- restore_cache:
keys:
- gem-cache-{{ checksum "Gemfile.lock" }}
- run: bundle check --path=vendor/bundle || bundle install --path=vendor/bundle
- save_cache:
key: gem-cache-{{ checksum "Gemfile.lock" }}
paths:
- vendor/bundle
- type: shell
command: |
bundle exec rspec --profile 10 \
--format RspecJunitFormatter \
--out test_results/rspec.xml \
--format progress $(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings) |
|
A small repo to reproduce this issue for us would be a huge help. |
|
@LarsFronius @thbar Can you reproduce it without parallel execution? I couldn't find related changes by quick code review in |
|
@hsbt I also got the error after using @colby-swandale I will try to create a small reproduction on CircleCI + GitHub once my consulting day is done (unless someone already provided something in the mean time). |
|
Can you also attach the output of |
|
@colby-swandale will do! |
|
Here is a reproduction:
To trigger the error, I had to shell out to |
|
Changes are visible at v1.16.1...v1.16.2 (to make it easier for someone to have a look). |
|
One last note for now: I only get failures on CI (docker + ubuntu on CircleCI, ubuntu on Travis), but could not get to trigger a failure locally (Mac, be with 2.3.7 or 2.5.1). |
|
In the case of @LarsFronius, I believe it may also be a matter of shelling out to |
|
Same error. Ruby versions 2.3.3 and 2.3.6. Reverting to 1.16.1 fixes it. |
|
Same error for us with ruby 2.4.4p296. We have some specs that shell-out to
|
|
Thanks for the input everyone, I've been looking into this issue but have not had much success in reproducing this issue on my machine. Any more information about your environment would be a huge help. Is this only happening in CI for everyone? What's the output of |
|
@colby-swandale Thanks for looking into this. I think this might have to do with bundle path overrides. I can reliably reproduce using @thbar 's example if I You can verify locally with docker if you'd like. Adding a Dockerfile: Reproduce with |
|
@colby-swandale I've only reproduced on GitLab CI so far. gitlab-ci.yml Replacing
with
works just fine. |
|
Thanks everyone for your help. I'm able to replicate this issue now 🙇♂️ |
|
A temporary workaround for this issue is to update RubyGems to the latest version |
lostie
referenced
this issue
in ministryofjustice/Claim-for-Crown-Court-Defence
Jul 18, 2018
Remove `gem install bundler` and `gem update --system` install script commands that had been used to patch travis errors previously as these now seem to be breaking the build. [example issue](travis-ci/travis-ci#8969)
Closed
5 tasks
stanhu
added a commit
to stanhu/carrierwave
that referenced
this issue
Aug 23, 2018
elia
added a commit
to opal/opal
that referenced
this issue
Aug 24, 2018
colby-swandale
added a commit
that referenced
this issue
Sep 6, 2018
colby-swandale
added a commit
that referenced
this issue
Sep 13, 2018
bundlerbot
added a commit
that referenced
this issue
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 issue
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)
colby-swandale
pushed a commit
that referenced
this issue
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)
|
This issue has been fixed in the newest release of Bundler. |
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this issue
Sep 23, 2018
## 1.16.5 (2018-09-18) Changes: - Add support for TruffleRuby (@eregon) Bugfixes: - Avoid printing git errors when checking the version on incorrectly packaged versions of Bundler ([#6453](rubygems/bundler#6453), @greysteil) - Fix issue where Bundler does not check the given class when comparing equality in DepProxy (@ChrisBr) - Handle `RangeNotSatisfiable` error in Compact Index (@MaxLap) - Check for initialized `search` variable in `LazySpecification` (@voxik) - Fix LoadError occurring in nested bundle exec calls ([#6537](rubygems/bundler#6537), @colby-swandale) - Check that Bundler::Deprecate is not an autoload constant ([#6163](rubygems/bundler#6163), @eregon) - Prefer non-pre-release versions when performing a `bundle update --patch` ([#6684](rubygems/bundler#6684), @segiddins) ## 1.16.4 (2017-08-17) Changes: - Welcome new members to the Bundler core team (@indirect) - Don't mutate original error trees when determining version_conflict_message (@greysteil) - Update vendored Molinillo to 0.6.6 (@segiddins) Bugfixes: - Reword bundle update regression message to be more clear to the user when a gem's version is downgraded ([#6584](rubygems/bundler#6584), @ralphbolo) - Respect --conservative flag when updating a dependency group ([#6560](rubygems/bundler#6560), @greysteil) - Fix issue where a pre-release version was not being selected when it's specified in the Gemfile ([#6449](rubygems/bundler#6449), @akihiro17) - Fix issue where `Etc` was not loaded when getting the user's home dir ([#6640](rubygems/bundler#6640), @colby-swandale) - Use UTF-8 for reading files including Gemfile ([#6660](rubygems/bundler#6660), @eregon) - Remove unnecessary `while` loop in path resolver helper (@ojab) Documentation: - Document that `bundle show [--paths]` sorts results by name (@kemitchell) ## 1.16.3 (2018-07-17) Features: - Support URI::File of Ruby 2.6 (@hsbt) Bugfixes: - Expand symlinks during setup to allow Bundler to load correctly when using symlinks in $GEM_HOME ([#6465](rubygems/bundler#6465), @ojab, @indirect) - Dont let Bundler create temporary folders for gem installs which are owned by root ([#6258](rubygems/bundler#6258), @colby-swandale) - Don't fallback to using temporary directories when needed directories already exist ([#6546](rubygems/bundler#6546), @brodock) - Use SharedHelpers.filesystem_access when reading a Gemfile so friendly error messages can be given to the user ([#6541](rubygems/bundler#6541), @segiddins) - Check if source responds to `#remotes` before printing gem install error message ([#6211](rubygems/bundler#6211), @colby-swandale) - Handle Errno::ENOTSUP in the Bundler Process Lock to prevent exceptions when using NFS mounts ([#6566](rubygems/bundler#6566), @colby-swandale) - Respect encodings when reading gemspecs ([#6598](rubygems/bundler#6598), @deivid-rodriguez) Documentation: - Fix links between manual pages (@BanzaiMan) - Add warning to Gemfile documentation for the use of the `source` option when declaring gems ([#6280](rubygems/bundler#6280), @forestgagnon) ## 1.16.2 (2018-04-20) Changes: - Include the gem's source in the gem install error message when available (@papanikge) - Remove unnecessary executable bit from gem template (@voxik) - Dont add the timestamp comment with gems added to the Gemfile via `bundle add` ([#6193](rubygems/bundler#6193), @cpgo) - Improve yanked gem error message (@alyssais) - Use `Bundler.rubygems.inflate` instead of the Gem::Util method directly (@segiddins) - Remove unused instance variable (@segiddins) Bugfixes: - Only trap INT signal and have Ruby's signal default handler be invoked (@shayonj) - Fix warning about the use of `__FILE__` in RubyGems integration testing (@MSP-Greg) - Skip the outdated bundler check when MD5 is not available ([#6032](rubygems/bundler#6032), @segiddins) - Fallback to the original error if the friendly message raises (@segiddins) - Rename Bundler.frozen? to avoid Object method conflict ([#6252](rubygems/bundler#6252), @segiddins) - Ensure the bindir exists before installing gems (@segiddins) - Handle gzip corruption errors in the compact index client ([#6261](rubygems/bundler#6261), @colby-swandale) - Check if the current directory is writeable when writing files in `bundle gem` ([#6219](rubygems/bundler#6219), @nilsding) - Fix hang when gemspec has incompatible encoding (@deivid-rodriguez) - Gracefully handle when the lockfile is missing spec entries for the current platform ([#6079](rubygems/bundler#6079), @segiddins) - Use Gem::Util.inflate instead of Gem.inflate (@hsbt) - Update binstub generator to use new ERB.new arity in Ruby 2.6 (@koic) - Fix `source_location` call in rubygems integration (@MSP-Greg) - Use `filesystem_access` when copying files in Compact Index Updater ([#6289](rubygems/bundler#6289), @segiddins) - Fail gracefully when resetting git gems to the given revision fails ([#6324](rubygems/bundler#6324), @segiddins) - Handle exceptions that do not have a backtrace ([#6342](rubygems/bundler#6342), @nesaulov) - Check if stderr was closed before writing to it (@shime) - Handle updating a specific gem for a non-local platform ([#6350](rubygems/bundler#6350), @greysteil) - Bump the `bundle_binstub` check-length to 300 characters (@tduffield) - Fix specifying alterntive Lockfile with `bundle lock` when default gemfile is present ([#6460](rubygems/bundler#6460), @agrim123) - Allow installing dependencies when the path is set to `.` ([#6475](rubygems/bundler#6475), @segiddins) - Support Bundler installing on a readonly filesystem without a home directory ([#6461](rubygems/bundler#6461), @grosser) - Filter git uri credentials in source description (@segiddins) Documentation: - Correct typos in `bundle binstubs` man page (@erikj, @samueloph) - Update links in `bundle gem` command documentation to use https (@KrauseFx) - Fix broken links between bundler man pages (@segiddins) - Add man page for the `bundle doctor` command ([#6243](rubygems/bundler#6243), @nholden) - Document `# frozen_string_literal` in `bundle init` Gemfile (@315tky) - Explain the gemspec files attribute in `bundle gem` template and print a link to bundler.io guides when running `bundle gem` ([#6246](rubygems/bundler#6246), @nesaulov) - Small copy tweaks & removed redundant phrasing in the bundler man page (@rubymorillo) - Improve the documentation of the settings load order in Bundler (@rubymorillo) - Added license info to main README (@rubymorillo) - Document parameters and return value of Injector#inject (@tobias-grasse)
maxlazio
pushed a commit
to gitlabhq/omnibus-gitlab
that referenced
this issue
Oct 24, 2018
A few reasons for this change: GitLab CE and Gitaly are now using bundler v1.16.6 to avoid rubygems/bundler#6537. 1.16.3 also ships with rubygems/bundler#6550, so we no longer need the patch for this.
jameszhan
pushed a commit
to jameszhan/gitaly
that referenced
this issue
Nov 13, 2018
The elusive rspec failures we were looking for were caused by this bug, which got fixed in bundler 1.16.5: rubygems/bundler#6537
|
Hi, I am getting same issue. But when I check bundle version, it shows error like this. I am not sure whey it shows this error. |
7 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Not sure if the issue is isolated to old ruby versions, but one of our customers does:
This reproducibly worked in bundler 1.16.1.
The text was updated successfully, but these errors were encountered: