Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot uninstall bundler in order to change the bundler version for ruby build #8717

Closed
dyg2104MD opened this issue Nov 6, 2017 · 6 comments
Labels

Comments

@dyg2104MD
Copy link

Uninstalling bundler with the following command fails

rvm @global do gem uninstall bundler

the error message is

ERROR:  While executing gem ... (Gem::InstallError)
    gem "bundler" cannot be uninstalled because it is a default gem

my build is on ruby 2.3.3, rvm 1.29.2, and rubygems 2.7.1.

i know that bundler will be a default gem in ruby 2.5.0 and above, but since i am using ruby 2.3.3 i would expect this to work.

@dyg2104MD
Copy link
Author

it looks like bundler is included as a default gem for ruby 2.3.3 on travis here

/home/travis/.rvm/rubies/ruby-2.3.3/lib/ruby/gems/2.3.0/specifications/default/bundler-1.16.0.gemspec

but i'm not sure why.

@MSP-Greg
Copy link

MSP-Greg commented Nov 7, 2017

It seems 2.3.4 & 2.4.1 also have gem issues with bundler.

See https://travis-ci.org/MSP-Greg/travis-ruby/builds/298359169

@BenFradet
Copy link

The default bundler install seems weird too, I personally only have an exe/ folder, no lib/ nor gemspec.

@AlexanderBelonogov
Copy link

Got the same issue when trying to use bundler with lower version. I fixed that by downgrade rvm:

before_install:
- rvm implode --force
- \curl -sSL https://get.rvm.io | bash -s 1.27.0
- rvm reload
- rvm install 2.2.3
- gem uninstall -i /home/travis/.rvm/gems/ruby-2.2.3 bundler -x
- gem install bundler -v 1.12.5

@Sharpie
Copy link

Sharpie commented Feb 18, 2018

Another strategy I've found effective is to remove the entry under specifications/default/ before installing the version I need:

before_install:
  - "find /home/travis/.rvm/rubies -wholename '*default/bundler-*.gemspec' -delete"
  - gem install bundler --version $BUNDLER_VERSION

Hacky and bothersome, but some day I won't be testing against a Vagrant dependency that is chained to specific versions of Bundler...

richardc added a commit to richardc/foodcritic that referenced this issue Mar 7, 2018
Use the workaround from
travis-ci/travis-ci#8717 (comment)
to remove the default bundler gemspec from RVM.

This fixes issues with the regression tests resolving to the incorrect
bundler, cauing this error with the 2.5.0 RVM:

  1) regression test with cookbook users should match expected output
     Failure/Error: command("git clone -q https://github.com/chef-cookbooks/#{name}.git .")

     Mixlib::ShellOut::ShellCommandFailed:
       Expected process to exit with [0], but received '1'
       ---- Begin output of bundle exec git clone -q https://github.com/chef-cookbooks/users.git . ----
       STDOUT:
       STDERR: /home/travis/.rvm/gems/ruby-2.5.0/bin/bundle:23:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-2.5.0/lib/ruby/gems/2.5.0/gems/bundler-1.16.1/exe/bundle (LoadError)
       	from /home/travis/.rvm/gems/ruby-2.5.0/bin/bundle:23:in `<main>'
       	from /home/travis/.rvm/gems/ruby-2.5.0/bin/ruby_executable_hooks:15:in `eval'
       	from /home/travis/.rvm/gems/ruby-2.5.0/bin/ruby_executable_hooks:15:in `<main>'
       ---- End output of bundle exec git clone -q https://github.com/chef-cookbooks/users.git . ----
       Ran bundle exec git clone -q https://github.com/chef-cookbooks/users.git . returned 1
     # ./vendor/bundle/ruby/2.5.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout.rb:293:in `invalid!'
     # ./vendor/bundle/ruby/2.5.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout.rb:280:in `error!'
     # ./vendor/bundle/ruby/2.5.0/gems/rspec-command-1.0.3/lib/rspec_command.rb:111:in `block in command'
     # ./vendor/bundle/ruby/2.5.0/gems/rspec-command-1.0.3/lib/rspec_command.rb:108:in `tap'
     # ./vendor/bundle/ruby/2.5.0/gems/rspec-command-1.0.3/lib/rspec_command.rb:108:in `command'
     # ./spec/regression/regression_spec.rb:11:in `block (4 levels) in <top (required)>'
     # ./vendor/bundle/ruby/2.5.0/gems/rspec-command-1.0.3/lib/rspec_command.rb:47:in `block (2 levels) in <module:RSpecCommand>'
     # ./vendor/bundle/ruby/2.5.0/gems/rspec-command-1.0.3/lib/rspec_command.rb:45:in `block in <module:RSpecCommand>'
@stale
Copy link

stale bot commented May 19, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 24 hours. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@stale stale bot added the stale label May 19, 2018
@stale stale bot closed this as completed May 20, 2018
garettarrowood added a commit to powerhome/cobra_commander that referenced this issue Aug 15, 2018
* Use #is_a_path? conditionally on Bundler version

* Use Bundler::VERSION

* Update setting Bundler to frozen with #set_local

* Force travis to install with correct Bundler version

* Resolve rubocop offenses

* Verify bundler version is not greater than 1.14.0 in travis

* Print the version

* Override install properly

* Overwrite script as well

* Force uninstall of bundler as suggestion in link

https://stackoverflow.com/questions/26481650/travis-could-not-find-bundler-1-7-4

* try moving it to before_install

* Try another tactic found on this travis-ci issue

travis-ci/travis-ci#8717 (comment)

* Turn condition in Gemfile into Bundler version log

* Create build matrix with multiple Ruby & Bundler versions

* Remove logging that creates test failures

* Fix wrong bundler version

* Add 2 more Bundler versions

* Use matrix of 1 Ruby & 2 Bundler versions

* Use Gem::Version to compare Bundler versions

* Use #respond_to? instead of looking at Bundler

* Remove duplication from #path?
dedene added a commit to zenjoy/authy-devise that referenced this issue Jan 4, 2019
ZilvinasKucinskas added a commit to ZilvinasKucinskas/doorkeeper that referenced this issue Jan 14, 2019
This issue travis-ci/travis-ci#8717
helped to bypass default bundler version.
markets added a commit to markets/invisible_captcha that referenced this issue Mar 17, 2019
fernand-o added a commit to monde-sistemas/brcobranca that referenced this issue Aug 13, 2019
gnclmorais added a commit to gnclmorais/cocoon that referenced this issue Nov 11, 2020
Trying this solution to the default gem problem: travis-ci/travis-ci#8717 (comment)
gnclmorais added a commit to gnclmorais/cocoon that referenced this issue Nov 12, 2020
Trying this solution to the default gem problem: travis-ci/travis-ci#8717 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants