Use Multiple Versions of Rubygems with Rvm

Use multiple versions of rubygems with rvm?

The correct way is to created different named (-n) installs of the ruby you want installed and name them according to the rubygem version you want such as

rvm --install use 1.9.2-nrg186 && rvm rubygems 1.8.6 && gem --list
rvm --install use 1.9.2-nrg1810 && rvm rubygems 1.8.10 && gem --list

The reason for this is that you can only have 1 version of rubygems active an any given time. This is also due to the fact that each ruby defines a dependency on a specific rubygems version that version is known or expected to work with (regardless of if it can work with another or not).

This is the expected way to handle the multiple rubygems requirement and to eliminate potential problems. See https://gist.github.com/1273035 for specifics detailing this.

How to manage multiple gemsets and ruby versions with RVM?

Here is how I like to do it...

1. Install a ruby with RVM
2. Switch to/use that ruby
3. Create a gemset for a project
4. Switch to/use that gemset
5. Install gems needed
6. create an alias that points to my chosen ruby & gemset
7. switch to/use that new alias (again, associated w/ a project)

Do this as many times necessary for your different projects that you want to keep separate from eachother.

Example:

$ rvm install ruby-1.9.2
...
$ rvm list

rvm rubies

=> ree-1.8.7-head [ i386 ]
   ruby-1.9.2-head [ i386 ]
   ruby-1.9.2-preview3 [ i386 ]

$ rvm use ruby-1.9.2-preview3

info: Using ruby 1.9.2 preview3
$  rvm gemset create my_project

info: Gemset 'my_project' created.
rvm gemset use my_project

info: Now using gemset 'my_project'
$ gem install httparty
When you HTTParty, you must party hard!
Successfully installed crack-0.1.8
Successfully installed httparty-0.6.1
2 gems installed
$ rvm alias create my_project ruby-1.9.2-preview3@my_project

info: Creating alias my_project for ruby-1.9.2-preview3@my_project.

info: Recording alias my_project for ruby-1.9.2-preview3@my_project.
$ rvm use my_project

info: Using ruby 1.9.2 preview3 with gemset my_project
$ ....

Now I have an entire environment dedicated to a particular project. This is great because I can experiment with all sorts of different gems/versions without worrying about stomping all over other projects that have very specific requirements.

Good luck!

Managing multiple versions of a Ruby Gem

You should use RVM to manage multiple versions of ruby and gems.
Visit followings links to have an idea of rvm and to install.

https://rvm.io/

https://rvm.io/rvm/install/

Only one version of Ruby works when multiple versions are installed

I had the exact same issue, except using rbenv with bash.

The perpetrator seems to be the echo "export RUBYOPT='-W:no-deprecated -W:no-experimental'" line in your .zsh file, I'm not sure if Ruby 2.6.5 understands it.

Remove echo "export RUBYOPT='-W:no-deprecated -W:no-experimental'" from your .zsh / .bashrc / .profile and restart your shell.

Ruby gems fighting for two separate versions of activesupport?

You'll need to downgrade your version of activesupport to a version that supports daemonkit - or look for an updated version of daemonkit. Your current version of rails / activesupport is newer than the version supported by your version of daemon-kit.

You can have multiple versions of activesupport in a single gemset, but only one of them can be activated at once.

How to use two versions of the same gem on the same ruby version in asdf?

Remember that Gemfile and Gemfile.lock should make it possible to have multiple versions of the same gem installed and the correct one will be selected based on whatever constraints are described.

The only time you'll need to force a single version is when dealing with command-line tools (e.g. rails or rake) where only one can be active at any given time.

Gemsets are a byproduct of a time before Bundler and Gemfile.

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.

Resolve multiple versions of rubygems

I have a feeling that you might be using a different version of ruby than ruby gems is. Either that or ruby doesn't know where to look for your gems.

See the the gem installation guide to ensure your environment is configured to use gems.

If you're still having problems after following instructions, ensure that you haven't got multiple versions of ruby installed. In the event that there are multiple version of Ruby available, make sure your scripts are calling the same version of Ruby as gem is. This is done by comparing the gem environment listing for RUBY_EXECUTABLE against your scripts' shebang line. Double check to follow any symlinks, because most distribution based installations of ruby will symlink /usr/bin/ruby to /usr/bin/ruby1.8

You should also check that your gems were installed by the same user who is running the script.

If you ran gem install without root privileges the new gems will be installed in your home directory. If you're running a script that depends on these gems as another user. Those installed gems will not be found. However, there's no problems if your gems are installed by root and a different user is running scripts that requires those gems.

I experienced this problem while switching from Ruby to Ruby Enterprise Edition. I found that I had to install all my required gems again using REE's instance of gem.

how can i install rubygems with rvm ? what is the difference between the two?

Yes, you can install gems with rvm. Use:

rvm use 1.9.2 # Make sure you're using the installed version
rvm gem install --version '3.0.3' rails

Updated to include specific version of the gem.

---

Related Topics