I have used the same script to setup ruby and gems via rvm for two users on the same machine. I have confirmed with rvm --version that I'm using the same version and things seem to be installing identically.
However, on one my $GEM_PATH is being set properly, on the other both $GEM_PATH and $GEM_HOME are both blank - I have confirmed this both by echo $GEM_PATH and within a ruby script reading ENV['GEM_PATH']
Is RVM meant to set $GEM_PATH? If so, any ideas why it hasn't for me?
Are you sure both machines are running the same set of ruby and gems?
If the first is running version a of ruby and version b of gems and the second one is running the system versions (very likely on OS X) then the second machine may have different gem paths.
Make sure to do
rvm use _version_you_want_
in both machines!
Related
I am setting up a simple ruby on rails app locally. It seems I have two different versions of ruby on mac and I would like to only use one. When I ran bundle install, it says Your Ruby version is 2.7.1, but your Gemfile specified 2.6.3. Then, I changed the line ruby '2.6.3' in my gemfile to ruby '2.7.1'. With this it ran bundle install properly. However, when I run rails server it says Your Ruby version is 2.6.3, but your Gemfile specified 2.7.1.
Why is it saying two different values for my Ruby version?
How do I get it to only use one version of Ruby?
If its relevant, I am on a mac and installed ruby using homebrew. If I run ruby -v in the terminal it says ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-darwin19]. I'm not sure why it says I have ruby 2.6.3.
There are to different versions because Mac OSX already includes one by default for system scripts (2.6). Homebrew install another one that never overrides o reemplace the System Wide version.
You are looking for a "Ruby Version Manager", are tools that allow you to install and use different versions of Ruby, even per project.
The popular ones are RVM and rbenv. Personally, i choose rbenv and I think that is the most widely used of both. Example of use:
# Install ruby 2.7
rbenv install 2.7.1
# Make ruby 2.7 the default version
$ rbenv global 2.7.1
# Or make 2.7 the default versión only on a specific project
$ cd myproject
$ rbenv local 2.7.1
# this create a ".ruby-version" file
This webpage always have the most recent and easy to use tutorial for setup a Ruby environment, depending on the OS and version.
https://gorails.com/setup/osx/10.15-catalina#overview
You have two different versions of Ruby installed, because MacOS natively comes with a standard installation of Ruby.
You also have rails pointing to the system version of Ruby. That version is usually under /usr/bin/ruby. The Homebrew installed version of Ruby (which is what you want) is located under /usr/local/bin/ruby unless you specified a completely different root path to install your brew packages.
Running brew config will give you a short list of data about your Homebrew configuration. Among them is an environment variable called HOMEBREW_PREFIX, which should look something like this:
$ brew config
....
HOMEBREW_PREFIX: /usr/local
....
I recommend placing /usr/local/bin first on your PATH environment variable so that you can easily use your brew packages via the CLI:
export PATH="/usr/local/bin:$PATH"
You may also want to look into setting the following environment variables for whichever shell you are using (examples given):
RUBY_ENGINE=ruby
RUBY_VERSION=2.7.1
GEM_ROOT=/usr/local/etc/ruby-2.7.1/lib/ruby/gems/2.7.1 (alias for GEM_HOME)
gem env gives a lot of great information on how Gems is configured.
I I had this exact problem and managed to fix it by running this command:
CFLAGS="-Wno-error=implicit-function-declaration" rbenv install 2.6.7
Note - I needed that version (2.6.7) please change it to the one you need
I found this on this blog post here - https://dev.to/rbazinet/fix-installation-of-ruby-using-rbenv-on-macos-big-sur-3432
I am interested in how RVM and rbenv actually work.
Obviously they swap between different versions of Ruby and gemsets, but how is this achieved? I had assumed they were simply updating symlinks, but having delved into the code (and I must admit my knowledge of Bash is superficial) they appear to be doing more than this.
Short explanation: rbenv works by hooking into your environment's PATH. The concept is simple, but the devil is in the details; full scoop below.
First, rbenv creates shims for all the commands (ruby, irb, rake, gem and so on) across all your installed versions of Ruby. This process is called rehashing. Every time you install a new version of Ruby or install a gem that provides a command, run rbenv rehash to make sure any new commands are shimmed.
These shims live in a single directory (~/.rbenv/shims by default). To use rbenv, you need only add the shims directory to the front of your PATH:
export PATH="$HOME/.rbenv/shims:$PATH"
Then any time you run ruby from the command line, or run a script whose shebang reads #!/usr/bin/env ruby, your operating system will find ~/.rbenv/shims/ruby first and run it instead of any other ruby executable you may have installed.
Each shim is a tiny Bash script that in turn runs rbenv exec. So with rbenv in your path, irb is equivalent to rbenv exec irb, and ruby -e "puts 42" is equivalent to rbenv exec ruby -e "puts 42".
The rbenv exec command figures out what version of Ruby you want to use, then runs the corresponding command for that version. Here's how:
If the RBENV_VERSION environment variable is set, its value determines the version of Ruby to use.
If the current working directory has an .rbenv-version file, its contents are used to set the RBENV_VERSION environment variable.
If there is no .rbenv-version file in the current directory, rbenv searches each parent directory for an .rbenv-version file until it hits the root of your filesystem. If one is found, its contents are used to set the RBENV_VERSION environment variable.
If RBENV_VERSION is still not set, rbenv tries to set it using the contents of the ~/.rbenv/version file.
If no version is specified anywhere, rbenv assumes you want to use the "system" Ruby—i.e. whatever version would be run if rbenv weren't in your path.
(You can set a project-specific Ruby version with the rbenv local command, which creates a .rbenv-version file in the current directory. Similarly, the rbenv global command modifies the ~/.rbenv/version file.)
Armed with an RBENV_VERSION environment variable, rbenv adds ~/.rbenv/versions/$RBENV_VERSION/bin to the front of your PATH, then execs the command and arguments passed to rbenv exec. Voila!
For a thorough look at exactly what happens under the hood, try setting RBENV_DEBUG=1 and running a Ruby command. Every Bash command that rbenv runs will be written to your terminal.
Now, rbenv is just concerned with switching versions, but a thriving ecosystem of plugins will help you do everything from installing Ruby to setting up your environment, managing "gemsets" and even automating bundle exec.
I am not quite sure what IRC support has to do with switching Ruby versions, and rbenv is designed to be simple and understandable enough not to require support. But should you ever need help, the issue tracker and Twitter are just a couple of clicks away.
Disclosure: I am the author of rbenv, ruby-build, and rbenv-vars.
I wrote an in-depth article: http://niczsoft.com/2011/11/what-you-should-know-about-rbenv-and-rvm/
The basic difference is where the shell environment is changed:
RVM: it's changed when you change Ruby.
rbenv: it's changed when you run a Ruby/gem executable.
Also, the thing about RVM is, it covers a lot more then just managing Rubies, it has a lot more than any other tool (there are others apart from RVM and rbenv: https://twitter.com/#!/mpapis/status/171714447910502401)
Do not forget about instant support you get on IRC in the "#rvm" channel on the Freenode servers.
So to summarise the excellent answers above, the main practical difference between RVM and rbenv is when the version of Ruby is selected.
rbenv:
rbenv adds a shim to the start of your path, a command with the same name as Ruby. When you type ruby at a command line the shim is run instead (because it is also called "ruby" and comes first in the path). The shim looks for an environment variable or .rbenv_version file to tell it which version of Ruby to delegate to.
RVM:
RVM allows you to set a version of Ruby directly by calling rvm use. In addition, it also overrides the cd system command. When you cd into a folder that contains a .rvmrc file, the code inside the .rvmrc file is executed. This can be used to set a Ruby version, or anything else you fancy.
Other differences:
There are of course other differences. RVM has gemsets out of the box, while rbenv requires just a little more hacking (but not much). Both are functional solutions to the problem.
The main difference seems to be when and how ruby is switched. Ruby is switched:
for RVM manually (rvm use) or automatically during change of directories
for rbenv automatically each time a ruby command is executed
RVM relies on the modified cd command and manual selection of Ruby by rvm use. rbenv uses wrappers or "shims" for all basic ruby commands as the default mechanism to select ruby. RVM creates wrappers for basic command line tools like gem, rake, ruby, too. They are used for example in CronJobs ( see http://rvm.io/integration/cron/ ), but they are not the default mechanism to switch the Ruby version.
Thus both methods select "automatically" the right Ruby version by overwriting commands and using wrappers. rvm overrides shell commands like cd. rbenv overrides all basic ruby commands such as ruby, irb, rake and gem.
rvm system
env > before
rvm jruby # or whatever
env > after
diff after before
Gives you approximately:
< GEM_HOME=$HOME/.gem/ruby/1.9.1
---
> GEM_HOME=$HOME/.rvm/gems/jruby-1.6.6
< GEM_PATH=$HOME/.gem/ruby/1.9.1
---
> GEM_PATH=$HOME/.rvm/gems/jruby-1.6.6:$HOME/.rvm/gems/jruby-1.6.6#global
*bunch of rvm_*
> MY_RUBY_HOME=$HOME/.rvm/rubies/jruby-1.6.6
> RUBY_VERSION=jruby-1.6.6
> IRBRC=$HOME/.rvm/rubies/jruby-1.6.6/.irbrc
And it prepends:
$HOME/.rvm/gems/jruby-1.6.6/bin:$HOME/.rvm/gems/jruby-1.6.6#global/bin
to $PATH
I am wondering how RVM manages the gem/gemsets. For instance, I have by default been using ruby 1.9.2#global and installed rails 3.1.3 in this environment. Later I copied a rails project from other, which is based on rails 3.0.10. By cd into the folder, I ran rails -v, it recommended me to run bundle install. I did so. After this, lots of gems were installed including rails 3.0.10. But when I do rvm 1.9.2 do gemset list, there is no new gemset( this is expected though). Then how do I manage the two versions of rails?
Thank you in advance
You can have more than one path into your Gem.path.
Try running ruby -r rubygems -e "p Gem.path" and check the output, you'll see that both #global and your current gemset are included.
Rubygems use the $GEM_PATH variable to figure out where to look/install gems, and that's one of the things RVM sets when you change a ruby version/gemset.
Also, it might be worth to look at a few environment variables RVM sets. Run this:
env | grep -i rvm||path
There might be a few extra ones (including $PATH), but you'll general you'll see a lot of RVM environment variables.
That's why some people like rbenv, a simpler way to manage ruby versions.
I set up RVM and used it to install Ruby and a few other libraries. As I was going through various tutorials and set-ups of other technologies like Rails, I began getting confused about what I should do via RVM and what I should just do as the tutorials suggest.
One example is the RubyGems tutorial here:
http://rubygems.org/pages/download
Should I download that tar file they are talking about? Seems unnecessary since that is what I thought RVM was for. Do I even need RubyGems? What is that for really?
Also, how do I actually get Rails? Is there a precise RVM command to actually download and install Rails?
It helps me to think of RVM as a layer of abstraction between you and the ruby ecosystem.
Without RVM: ruby, gems, and ruby related binaries (like rake, spec, gem, etc) are all installed directly into your operating system directories.
With RVM: ruby related stuff is intercepted by rvm so that ruby, gems, and ruby related binares are "installed" into ~/.rvm dir in a nice, clean, organized way. RVM sits between ruby, gems, and related binaries and the operating system. It provides a way to have multiple ruby environments (with different gems and binaries) on the same machine.
So, no matter whether you have rvm installed or not, you should be able to run the commands almost exactly(*) as they appear in any tutorials out there on the web. In other words, you can sort of "forget" that RVM is installed; the ruby ecosystem should work just as if it wasn't installed.
So, yep, you're gonna have to run gem install rails, etc.
Hope that helps clear the confusion.
(*) There are some small differences. For example: you shouldn't run commands as sudo when RVM is installed.
Should I download that tar file they are talking about?
No. Ruby 1.9+ includes gems. RVM retrofits it for 1.8+.
In general, be careful with any directions you find on the internet explaining how to install anything, unless you have enough experience to understand completely what they want you to do. In particular, any time they want you to install something using sudo or as root.
Specifically, when working with RVM, you do NOT want to use sudo to install Ruby, or any gem. RVM works by setting up a sandbox for your development, and relies on your account's environment, modifying your path so any Ruby requests go to the currently selected RVM-managed Ruby or gems or any commands they install. sudo pushes your normal environment to the side, substituting root's temporarily, installs whatever you asked it to do with root's permissions, then reverts to your environment.
When you go to run the command, or find the gem, as you, it can't be found by RVM's Ruby, because the file was installed outside RVM's sandbox, or, it can't be read or modified, because it's owned by root. Whatever the actual cause, the end result will be weeping and gnashing of teeth.
RVM doesn't subvert the gem functionality. gem is used to install and manage Ruby gems, and RVM tweaks it to use the sandbox for all its machinations. You get added functionality because of RVM's support of gemsets, but gem works as it always has, only it has "big brother", RVM, controlling its world.
No need to install rubygems. RVM should have already installed rubygems. RVM is (in my opinion) useful for managing different installations of ruby (say 1.8.7 and 1.9.2) or different gemsets. If you just have one version of ruby and don't care about different gemsets, RVM isn't really that much of a change. If you want to just install rails, just use gem install rails. If you have an existing rails 3 app, install bundler first gem install bundler and then bundle install to get rails and other gem dependencies.
I used railstutorial.org to install the latest version of ruby and the latest version of rails on my machine.
at the end of the installation I checked
ruby -v ==> 1.9.2 (great)
rails -v ==> 3.0.1 (great)
this morning I opened up terminal
ruby -v
ruby 1.8.6 (2009-06-08 patchlevel 369) [universal-darwin9.0]
rails -v
Rails 1.2.6
what happened?
My advice for people who are installing ruby is to use RVM. It makes managing your ruby versions and gem versions really simple and you can install multiple ruby versions side by side.
You might want to read this post:
http://rubylearning.com/blog/2010/12/20/how-do-i-keep-multiple-ruby-projects-separate/
You can use Cinderalla to the whole ruby/rvm/mysql/redis/git/... stack set up properly. Cinderella installs everything in ~/Developer and fixes up your PATH as well. I had some issues with a corrupt git mirror last time I used Cinderalla though so YMMV.
With many unix variants, you are likely to have multiple versions of Ruby--particularly if you installed Ruby 1.9 and the system already had 1.8 installed. Essentially, the 1.8 version of Ruby has a higher precedence in your PATH than the 1.9 version. The Ruby Gems command keeps the libraries separate between 1.8 and 1.9 so that the platform will be reasonably stable.
To correct the problem, you have to find where ruby 1.9 is installed. Once you do that, you'll need to override your PATH variable. Assuming 1.9 is installed in the path: /opt/ruby-1.9.2, you will need to set your PATH like this:
PATH=/opt/ruby-1.9.2/bin:$PATH
export PATH
To make the path respect what you want every time, add that to your ~/.profile file (create it if necessary). Once the path has been set, it sould be able to find the correct version of Rails again.
I cannot say for certain because I cannot debug you OSX machine from here, however, I had a very similar occurrence. The problem was caused because I had installed ruby and then rails on my machine using sudo or from the root account. Then when I discovered rvm I installed everything in my user account. When I logged off and back in I appeared to lose everything. I was pulling out my hair. I was pissed that I was going to have to reinstall everything again... when I found the magic.
from the command line execute the command:
rvm list
you'll see that your new version of ruby is there. you'll also notice the tokens that indicate that it is just a normal version. It is not current or default. (see it yet)
Now if you run the command:
rvm use 1.9.2 --default
then every time you login/off and restart your machine your user account will default to that version of ruby and all of the gems that you installed against that version.