Bundle Install Is Using a Different Ruby Version

Bundle install is using a different Ruby version?

Please do the following steps to fix the problem:

  1. Make sure that the following commands returns the proper version of ruby:

    $ rbenv versions
    system
    2.0.0-p353

    $ rbenv local
    ruby-2.0.0

    $ rbenv version
    2.0.0-p353
  2. Make sure that getting the version of ruby is correct:

    $ bundle exec ruby -v
    ruby 2.0.0-p353 (2013-11-22 revision 43784) [x86_64-linux]
  3. If you got invalid version of ruby, you shell to verify that problem is in bundler by calling:

    $ bundle exec ruby -v
    ruby 1.8.7

    $ which bundle
    /usr/bin/bundle

    It says that it will call system ruby to proceed ruby scripts.

  4. Reinstall bundler, and then make sure that now current ruby is valid:

    $ gem install bundler

    $ bundle exec ruby -v
    ruby 2.0.0-p353 (2013-11-22 revision 43784) [x86_64-linux]

Also refer to how to properly set up a ruby project, which is being developed under rbenv/rvm here:

bundler using system ruby version instead of downloaded

Okkk, so after hours and with help from comments here and the answer given above I was able to get it to work.

The problem it seemed was that rbenv was not properly setup. To fix it, it's either to uninstall and install again. Did this through:

  1. brew remove rbenv
  2. rm -rf ~/.rbenv
  3. Removed a line containing rbenv from ~/.zshrc

This removed rbenv. I then reinstalled using:

  1. brew install rbenv
  2. Then initialized using rbenv init. This effectively fixes the problem of rbenv. Now after restarting terminal, whenever I ran which ruby, I'd get:

/Users/Mahmoud/.rbenv/shims/ruby

meaning in short that the system now relies on rbenv for its ruby version management instead of looking in the system. This is crucial for the working of rbenv, and in essence this is it's whole "raison d'etre"; to take the job of managing ruby on your pc away from your pc.

After this step I ran gem install bundler. Following this step when I run which bundle it would give:

/Users/Mahmoud/.rbenv/shims/bundle

so everything is in place and working fine

Bundler using an older Ruby version

TL;DR Change the version of Ruby from 2.1 to 2.3 in /usr/local/bin/bundle.

Explanation

To figure out which Ruby bundler is using enter

which bundle

This should print

/usr/local/bin/bundle

Now open the file and change the Ruby version from 2.1 to 2.3

Ruby Bundler - Multiple Ruby versions in the same gemfile

Gemfiles Declare Dependencies

A Gemfile declares a dependency on a Ruby version, with or without semantic versioning constraints. It is not meant to control multiple build targets for your application. It simply enforces that the Ruby version available to your app/gem is whatever you've defined. For example:

# Will fail if run with a different RUBY_VERSION.
ruby '2.2.4'

# Allows RUBY_VERSION >= 2.2.4, but <= 2.3.
ruby '~> 2.2.4'

# Allows either Ruby 2.2.4+ or 2.5.5+, with
# a minimum (but no maximum) patch version.
ruby '~> 2.2.4', '~> 2.5.5'

However, it won't install a given Ruby, nor do anything other than raise an error and a non-zero exit status when running bundler install. You need to take a different approach to test multiple targets.

Changing Build Targets with Continuous Integration (CI) Tools

If you're using an external CI like TravisCI, you can create a build matrix that targets multiple Ruby versions to test against. Whether you remove the Ruby version constraint altogether, or specify a supported range, is up to you. Leveraging your CI tool to build against the versions of Ruby you plan to support is really the best approach, though, whether or not you constrain your Ruby runtime in a Gemfile.

For example, you might use a matrix in your travis.yml like so:

language: ruby
rvm:
- 2.2.4
- 2.5.5

Switching Gemfiles

If you insist on doing it the way you're doing it, with a singular Ruby version allowed in your Gemfile, then you might consider having two separate gemfiles with different names in your source tree, such as Gemfile-2.2.4 and Gemfile-2.5.5. You can then specify which Gemfile to use with Bundler's --gemfile flag , or by symlinking a custom Gemfile to the canonical Gemfile for your project.

Here are some examples to consider:

# Resolve against a specific Gemfile with
# hard-coded Ruby version.

$ ls Gemfile*
Gemfile-2.2.4 Gemfile-2.5.5

$ bundle install --gemfile="Gemfile-2.2.4"
# Resolve against whatever custom file is
# symlinked to your ./Gemfile.

$ ln -sf Gemfile{-2.5.5,}

$ ls -F Gemfile*
Gemfile@ Gemfile-2.2.4 Gemfile-2.5.5

$ bundle install

Both approaches work, but the former is more flexible at the cost of needing to specify your chosen Gemfile each time, while the latter can help when you have a development/testing workflow that doesn't support Bundler's --gemfile flag.

Changing Rubies with Ruby Managers

If you have multiple Ruby versions in development, best practice is to use a version manager such as rvm, rbenv, or chruby. You can use your version manager to change rubies back and forth manually as needed.

You might also check whether your version manager supports auto-switching on .ruby-version or other configuration files. You'd still have to update that file each time you want to build or test against a different Ruby, but you wouldn't have to keep changing your Gemfile contents, re-pointing the Gemfile symlink, or updating a flag on each call to Bundler.

Whether or not any given approach is better than others will depend on your workflow. No technical solution will fit all circumstances, so your mileage may legitimately vary.



Related Topics



Leave a reply



Submit