I have a an app that runs and is installed on JRuby in production. The same app can run in Ruby 1.8.7 as well in development. How can I use RVM to switch between these rubie?
I am looking for a .rvmrc-like solution so that I can say
rvm use .rvmrc_ruby
or
rvm use .rvmrc_jruby
to switch between Ruby versions. I usually need to do this to test the same app on both Ruby and JRuby.
I would like a solution where I can check-in such settings to Git and run these things without having to type the Ruby versions or gemset names everytime I need to switch.
generate those two files and in .rvmrc write:
source ./.rvmrc_${TEST_WITH:-jruby}
then you can write in your shell:
export TEST_WITH=ruby
cd .
and restore with:
unset TEST_WITH
cd .
This seems silly.
First, why are you even bothering to run a different Ruby in development? If this is for the occasional test run to ensure compatibility across different Rubies, then okay, but then…
Second, all you probably have in your .rvmrc is rvm use 1.8.7 or rvm use jruby—that is all that happens when your .rvmrc file runs. What's so bad about just actually typing that out into the terminal? It's actually less characters than the example commands you gave, and you get tab-completion too. If you need consistency across shells and actually have to have the .rvmrc reflect the current Ruby you want, then just change the file. Or, if you really must, write a simple script to do it for you (say it's called changervmrc.sh):
#!/bin/bash
echo "rvm use $1" > .rvmrc
and invoke with ./changervmrc.sh jruby. You could adapt this to include switching to a specific gemset if needed.
Related
We are using RVM to manage rubies and gemsets for dozens of projects.
Sometimes I'll either edit the .ruby-version or .ruby-gemset file, or pull a newer version of those file(s) from our VCS, but of course RVM is unaware of these changes unless I tell it. And if the changes come from the VCS, even I may not be aware of them. So what's the best way to do this?
It would be nice to be able to automate the process, so that it is done automatically any time I fetch changes from the repository.
The only way I know of to get RVM to re-read these files is to cd to another directory, then return to the project directory. This is obviously simple, and easy, but it seems more than a little inelegant, and isn't self-documenting.
I'd expect there to be some command like rvm reload (which exists, but does something else) to re-read the project files, but I can't find anything of the sort.
I think I've found an answer, but as it is undocumented I don't know if it's really legit.
It seems that if you do:
$ rvm use .
It'll apparently (re)read the .ruby-version and .ruby-gemset files (not sure of .rvmrc files, since we don't use them). I discovered this by trying rvm use .ruby-version and rvm use .ruby-gemset, both of which seemed to cause RVM to read both 'dot' files.
This functionality is not currently (as of RVM 1.23.13) mentioned in the documentation (i.e. rvm help use).
Maybe it should be?
I use .rvmrc and I used to do
cd;cd -
but now I do
cd .
If I do
rvm use .
I get
Could not determine which Ruby to use; . should contain .rvmrc or .versions.conf or .ruby-version or .rbfu-version or .rbenv-version, or an appropriate line in Gemfile. ( see: 'rvm usage' )
which I don't really think is true (because I do have a .rvmrc file in .), or perhaps I just don't understand.
Edit:
I am using rvm 1.25.33
I didn't mean to come across as critical, just trying to add more info!
I have just installed RVM in my machine and facing problem with rvmrc file, can anyone help me out, how to create rvmrc?
I just did:
rvmrc --create ruby-1.8.7-p352#gemset
but didn't get the result...
It seems that there is a small mistake. Inside your .rvmrc file add:
rvm use ruby-1.8.7-p352#gemset --create
Also you might want to change the name of your gemset to something that is a bit more intuitive to read :)
UPDATE
Using the rvmrc file has now been deemed deprecated. Instead a .ruby-version file with the ruby version e.g. '2.0.0' and a .ruby-gemset file with the gemset name e.g. 'monkeys_of_doom'
This way developers using other version managers such as rbenv can pick up the ruby version in an automated fashion.
rvm --rvmrc --create ruby-1.8.7-p352#gemset
Read this article. http://net.tutsplus.com/tutorials/why-you-should-use-rvm/
If the gemset already exists, it is sufficent to add rvm ruby-1.8.7-p352#gemset to the .rvmrc file, which can be achieve for instance by
echo "rvm ruby-1.8.7-p352#gemset" > .rvmrc
UPDATE: it looks like the .rvmrc file format is deprecated, and the usage of .ruby-gemset and .ruby-version files is encouraged instead. If "rails2.3.5" is your gemset name, then one would require the following two commands
echo "ruby-1.8.7-p352" > .ruby-version
echo "rails2.3.5" > .ruby-gemset
I found working solution (http://sirupsen.com/get-started-right-with-rvm/)
rvm --create --rvmrc 1.8.7#project
you can also do this
rvm --rvmrc --create use ruby-1.9.3-p194#myproject
Instead of rvmc use:
rvm --create --ruby-version ruby-2.1.04#my-project
will generates the .ruby-gemset and .ruby-version files
The definitive documentation is at https://rvm.io/workflow/rvmrc/ for how to create rvmrc files, and the global .rvmrc parameters that affect them.
The --rvmrc parameter is what actually creates the rvmrc files, then you have to run
rvm rvmrc trust .
in the project directory to generate, and record, the security md5 hash to use that rvmrc file. The command 'trusts' the file so you're not prompted to trust it every time you enter the directory.
here is another much simpler approach
rvm use 1.8.7#gemset --create
first you need to create a rvmrc like -
rvm --rvmrc --create use ruby-2.2.1#gemset_name
Then run
rvm rvmrc trust .
That will resolve the issue for selecting rvm for differnt application.
Hope you enjoy. :)
For creating rvmrc file with specific ruby and gemset then use below command -
rvm --rvmrc --create ruby-with-version#gemset_name
like:
rvm --rvmrc --create ruby-2.3.3#rails5
Now we should need to select project location for change reflection so type cd .. and hit enter in terminal
Again type cd project_name/ for selecting our project but now you get * Notices something like below image so here you just type y and hit enter.
Now you have successfully created rvmrc file so from now no need to select gemset each time on selecting different projects.
I installed ruby 1.9.3 using RVM. I want to use 1.8.7 interpreter whenever I open a new terminal session. Currently I have to type rvm system every time I open the terminal.
To quote RVM's documentation:
If you wish to switch back to your system ruby as default, remember
that RVM does not "manage" the system ruby and is "hands off".
This means to set the "system" ruby as default, you reset RVM's
defaults as follows:
rvm reset
I not sure about reverting back.. But you can use .rvmrc file to avoid keep on typing rvm system command. Create a file in the name of .rvmrc and store the command rvm system in it. Move the file to specific path.. In your case in home/root folder. Now by default. It will use system ruby. check the below link for more details
rvmrc
I come in peace (re: rbenv) but I am super frustrated with rvm & .rvmrc. I keep on running into issues where I cd into my project folder only to find that my ruby & gemset environment has not been set correctly. So can someone once and for all tell me how to create a proper .rvmrc for my project.
I have tried both ways that I know of:
creating a .rvmrc and putting 'rvm use 1.9.2#GEMSET' in there (this works sometimes and sometimes not)
using the rvm --create --rvmrc 1.9.2#GEMSET command line tool which creates a more ellaborate .rvmrc but cd'ing into my project folder is still not giving me the desired result.
This problem is erratic. I will say that I am working on two different machines and syncing my project folder via Dropbox. So could this be a problem where rvm cannot verify the folder and therefore ignores the .rvmrc?
Any help will be greatly appreciated.
Every time you enter a project directory after changing its .rvmrc file, rvm will prompt you for accepting or not the new file. If you want to change your decision afterwards, you should use rvm rvmrc command:
rvm rvmrc {trust,untrust,trusted,load,reset}
You may need to set
rvm_project_rvmrc=1
in your shell config before the rvm scripts are sourced, e.g.:
rvm_project_rvmrc=1
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
Considering putting RVM into production (light duty) on a new machine. But I'm not visualizing how it will work if a user isn't logged in. RVM has been installed into /usr/local/rvm/bin/rvm so it is available to "everyone".
If server restarts and is at login screen and background daemons are serving apache/rails, etc. and no .bashrc, etc. have loaded...how/where do we specify which of RVM's Rubies to load?
Perhaps somewhere in Phusion's Passenger?
who manages these gemsets? are they shared?
You can use RVM's wrapper command to generate scripts that load up the correct RVM environment before executing the necessary binaries. The format is:
rvm wrapper [ruby_string] [wrapper_prefix] [binary[ binary[ ...]]]
For example, to create a binary named system_unicorn that loads ruby-1.9.2-p180 and then executes unicorn, use the following:
rvm wrapper ruby-1.9.2-p180 system unicorn
You can pass multiple binaries to create wrappers for. For example, to create wrappers for both unicorn and god, run
rvm wrapper ruby-1.9.2-p180 system unicorn god
ruby_string can be anything you can pass to rvm use, and thus can contain gemsets as well; for example, to create myapp_unicorn for the gemset my_app_gemset, use:
rvm wrapper ruby-1.9.2-p180#my_app_gemset myapp unicorn
When you install Passenger these days, it automatically creates a wrapper for it's ruby (pretty sure it calls it passenger_ruby) that loads up the correct version of Ruby (the one you're using when you install it). You can use config/setup_load_paths.rb to specify a gemset--see this Stack Overflow answer.
I've dealt with this in the past by running all jobs with a user that has rvm set up. It does add complexity to many simple jobs because you have to make sure that rvm is loaded. If you need to run commands as root AND use rvm, you can use the rvmsudo command.
You can also install RVM systemwide as root:
https://rvm.beginrescueend.com/rvm/install/
1) root installs the ruby versions and gems under RVM if you install them globally
(read the RVM readme -- there seem to be possible problems when installing globally!)
2) if you're on UNIX, each of your system processes gets started as a particular user,
e.g. on LINUX through the init-scripts in /etc/init.d/ ... while the processes are
created as a particular user, the mapping of user names to UID/GID, the home directory,
and login-shell are looked up in the /etc/passwd file
-- that is where the login shell (e.g. bash) is defined for a particular user.
So, coming back to your statement:
If server restarts and is at login screen and background daemons are serving apache/rails, etc.
and no .bashrc, etc. have loaded...how/where do we specify which of RVM's Rubies to load?
You see the problem with that statement?
When the server starts, and the background processes are started, each of them gets started as a particular user, with a particular login shell and with a particular home directory.
RVM will need that you have your login shell set to /bin/bash -- otherwise it couldn't set up the RVM environment for any of the processes that are run by that particular user. e.g. RVM will not work if you use /bin/nologin as the default shell.
Problem1:
That's a security problem of course! In general, daemons should not have a shell set for security reasons.
Problem2:
You don't want to make high-powered tools available to somebody breaking into your server - that's why you shouldn't have cc and other tools on a production server - that's why you should not compile your Rubys and Gems on the production server, but rather copy the .rvm directory onto the production servers...
Problem3: (more general)
The way RVM manages all it's Ruby and Gem versions is very very kludgy approach to version management..
Using special features of one particular login shell to facilitate the version management is not a good idea IMHO - sure there is nothing better at the moment, but in the old days, the idea behind Lude was a far better approach to install different versions of software:
http://www.iro.umontreal.ca/contrib/lude/lude2_toc.html
Conclusion:
So as I mentioned in a previous post, I highly recommend to set up RVM a normal user account to run your Ruby and Rails processes and to set up that one account with /bin/bash as the login shell and to copy your .rvm directory from your dev-server to your production machines via scp or rsync -- it's the better and safer approach.
I had a similar problem, where I want to deploy the ruby version and all associated gems to the production machines...
Because of the reasons outlined in my other post, I chose to go with a local RVM install. I have a user "deploy" on both my dev-servers and my production servers.
I would highly recommend that you use either "rsync' or 'scp -rp' to copy the complete subdirectory ~/.rvm to the target machine (remember that you don't want to have cc and other tools on a production server!)
One important Gotcha:
be sure that you use the identically named user account on all machines, if you replicate the .rvm directory!
I noticed that the internal book-keeping of RVM keeps track of some environment variables during installation of Ruby versions and gems, and that it keeps track in particular of the name of the user account that was used, and the path to the users's home directory. Beats me why they don't use $HOME and $USER , which are standard on all UNIXes.. seems like a real bug in RVM to me.
if you use the same user account for all machines, it will work just fine.
e.g. I use a user "deploy" which has the .rvm directory and which owns the running processes.
UPDATE
if you use rsync or scp to sync your deployment account, the downside is that you need to restart your servers, e.g. unicorn, manually.
Another promising way of deploying RVM and Rails apps is to deploy to one machine, where bundle update is run, and then create an RPM out of the whole deployment account, which is then installed via rpm -Uhv or a private yum repository onto all the nodes. Advantage here is that the services on the nodes can be easily restarted via a %post action in the RPM.