Just getting started with Ruby.
I am trying to use rvm. Now, for Project A I am trying to specify a specify Ruby version and a gemset.
$ cat projecta/.rvmrc
rvm 1.8.7#projecta
My understanding is that the part before # specifies the Ruby version and the the part after # specifies the gemset name. A gemset IMU is to provide a project specific isolated location where you can install gems.
After I check-in this project, what can I do to automate the process of creating the gemset and installing the correct Ruby version for someone else checking the project out at a later date?
Please suggest appropriate alternatives, since I am just getting started with Ruby today.
The Old Way
to make sure gemset / ruby is available use this .rvmrc:
rvm use 1.8.7#projecta --install --create
It will install ruby if missing and create gemset if missing.
And a special note, please do not use 1.8.7, it's deprecated ruby, with almost no support (security patches till half of 2013), you should stick with latest available ruby:
rvm use ruby
which at this time is: 1.9.3-p194
Add On-Demand Syntax
Your syntax won't work as written. If you want to force people to compile rubies and create gemsets on demand, rather than being warned when things don't exist, you want a project .rvmrc file like this:
# Compile rubies on demand.
rvm_install_on_use_flag=1
# Create gemsets on demand.
rvm_gemset_create_on_use_flag=1
# Use ruby-1.8.7 while in project tree.
rvm use 1.8.7
# Use gemset "projecta" while in project tree.
rvm gemset use projecta
There are certainly other ways to do it, but this way makes everything explicit, and you can comment out individual lines if you need to do so.
See Also
https://rvm.io/workflow/rvmrc/
Related
There is fundamental problem with ruby gem sets where commands like rake xxxx might create error because command might use global version of rake while your gemfile requires very specific version.
I know 2 ways to mitigate this.
Use bundle exec in front of rake and rails commands. For example bundle exec rake db:migrate Adding this in front makes sure command is executed in relation of the current bundle meaning the bundle that got created when you run bundle install.
Using RVM. There is less known way of creating local gemset with RVM. First you create directory for your new app in this case mkdir myapp, cd myapp and then run rvm use ruby-2.3.0#myapp --ruby-version --create for creating local gem set with nothing in it. Now you can run gem install rails and rails new . to create rails myapp with it's dedicated gem environment in the folder you are in.
As nice extra RVM will swap to right gemset every time you cd to myapp directory automatically.
As for as I understand both approaches work, but are there any known issues why you would not use one of approaches above?
If you're an RVM fan like myself, I would go with creating my own gemset for every rails project I start. This will make it easier for me to just use rake and rails commands without specifying bundle exec every time.
Put in mind when sharing your code that some developers might be using rbenv or maybe not using a ruby version manager at all. One way you can make sure that everyone is happy and working with the same version of ruby, is to provide two additional files in your project directory (.ruby-version and .ruby-gemset) and track them in your project.
The .ruby-version file would contain the version of ruby you're using for example 2.4.1. Note that this is compatible with both RVM and rbenv and will switch to the correct ruby version.
The .ruby-gemset file is identified only by RVM; thus, switching to the correct gemset you have setup for the project.
This will make your project compatible with developers using rbenv while still making those of us using RVM happy :)
Putting all these considerations in mind, now you should care less wither people use bundle exec or not!
One reason not to use (2): if anyone else wants to work with your code, they will have to duplicate all that for themselves, rather than just remembering to type bundle exec. They have likely never seen (2) before, so this is perhaps non-trivial.
I cloned a project and it had a .ruby-version file to specify ruby version of the project. content:
2.0.0
when I switched into the project dir for the first time it gave me warning:
ruby-2.0.0-p645 is not installed. To install do: 'rvm install
ruby-2.0.0-p645'
However it's true that my system didn't have Ruby 2.0 but Ruby 2.2 instead. Does that warning makes sense? Is there a way I use duplicate functionality of (~>) gem dependency in ruby-version file?
Based on the warning, you are using rvm. As another answer says, rbenv can also use a .ruby-version file, but switching to rbenv isn't neccesary, and won't really change anything.
I don't think rvm's .ruby-version file supports a range of versions. It needs to specify a version name that could be passed to rvm use, and I don't think there's any way to say a range of versions there.
You can:
Install ruby 2.0.0 with rvm: rvm install 2.0.0. When you switch into the project directory, rvm will automatically switch you to using ruby 2.0.0 like the .ruby-version file directs.
Simply change your .ruby-version file to specify the version of ruby you want to use instead. Just edit it in a text editor, or run rvm --ruby-version use 2.2.3 to have it write the .ruby-version file for you. Now when you switch into the project directory, rvm will automatically switch you to 2.2.3.
Delete the .ruby-version file entirely. You aren't required to use it. Personally, I don't use them and don't find them helpful. The .ruby-version file is meant to force a particular version of ruby to be used in that project -- but most projects work with multiple versions of ruby, and this isn't really neccesary, and as you've seen can be a headache when it's out of date and is trying to force you to use an older version of ruby, when a newer one would probably work fine.
.ruby_version is used for rbenv
You should install rbenv
or create .rvmrc for rvm
Using RVM I can generate docs using:
rvm docs generate
My question is do I have to do this for every gemset, or is it global?
I frequently switch gemsets while working on different projects. I would like to have ri always available. Does the above command generate the docs for all gemsets or just the current one?
It seems that the docs would have to be gemset specific so that different gems and versions of gems would be documented correctly in the environment you are in. Is the rvm docs command smart enough to make sure every gemset has documentation, or must I re-run this command for each gemset?
Apologies for the topic title, couldn't resist.
Basically, For no reason whatsoever apart from trying out different things. I want to implode RVM and try out rbenv. Nothing against RVM, just want to try different peoples software and try different things out.
I can get rid of RVM and install rbenv no problem. Could you guys confirm a few things for me.
Firstly, if I do the above, and then install a few different ruby versions. I know I can place a .ruby-version file in a projects root directory to specify a specific ruby version but then when I say gem install <gemname> I take it that is installed globally for that ruby version.
If I then use bundler per project to manage what gems are used and I specify a gem version, what happens if the version specified in the lock file is different to the currently installed version and what happens if it's vice versa?
I just need a bit of clarification on what's doing what in regards to ruby, versions, gems and their versions.
One of the (many) lovely things about rbenv is that you can so easily look right at your ruby installation to see what's going on. For example, on my machine I can open ~/.rbenv and there's versions containing my ruby installations, such as 1.9.3-p327. Opening that, I can keep drilling down to see my gems installed for that version of ruby (in ~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems). It is then trivial to run gem list or gem install somegem and confirm that what's being affected is this very collection of gems - if this is the current ruby (set in rbenv global and starred in rbenv versions).
In short, everything about your system thinks that ruby means this version of ruby and that its library is this library.
For Bundler, you'll need to install rbenv-bundler. A nice tutorial (easily found with Google) is here: http://dan.carley.co/blog/2012/02/07/rbenv-and-bundler/
Bundler 1.2.0.pre includes a new "ruby" DSL option. According to Heroku's documentation, they use this new Gemfile syntax to control which ruby version is used when you push your app.
Being pre-release, documentation for the new Bundler option is fairly thin on the ground at the moment, and the Bundler 1.2 roadmap simply lists it as "ruby version check".
My question is: currently I use a one-line .rvmrc file in most of my projects, in which I only specify the ruby version for that project (eg. rvm ruby-1.9.3). I don't use RVM gemsets or anything else (I prefer to vendor all of the required gems within the project, and let Bundler manage the dependencies).
Given my trivial RVM config, will the new "ruby" option in Bundler's DSL mean I no longer need to specify a .rvmrc file at all? Or are they two different things?
(I do like the fact that RVM automatically switches the ruby version when I cd into my project...not sure if Bundler would do that, or if it just warns when the current version doesn't match?)
the new ruby is a function and it will allow anything that finally evaluates to a string.
Unfortunately o read it you would need to use a bundler command which assumes you already have a ruby.
Instead RVM gives you two ways to defining ruby in Gemfile:
1) ruby "1.9.3" - simple strings
2) #ruby=1.9.3-p125 - a comment when you want to use ruby code for ruby or when you want to specify patchlevel or gemset!:
#ruby=1.9.3
ruby ENV['RUBY_VERSION'] || '1.9.3'
Will allow bundler to work with any ruby loaded by RVM but by default will use 1.9.3 from #ruby=