Instantly share code, notes, and snippets.
Save fnichol/1912050 to your computer and use it in GitHub Desktop.
I've been using this technique in most of my Ruby projects lately where Ruby versions are required:
- Create
.rbenv-versioncontaining the target Ruby using a definition name defined inruby-build (example below). These strings are a proper subset of RVM Ruby string names so far... - Create
.rvmrc(withrvm --create --rvmrc "1.9.3@myapp") and edit theenvironment_id=line to fetch the Ruby version from.rbenv-version(example below).
Today I learned about another Ruby manager,rbfu, where the author is using a similar technique with.rbfu-version.
What if we had an ecosystem of fabulous Ruby managers that all understood the semantics of a generic dotfile such as.ruby-version? The file's contents would be nothing more than a string representing a version of Ruby.
Without a more thorough investigation (here be dragons?), the project-level updates might be:
- rvm: A modification toscripts/functions/rvmrc to check for
.rvmrcand then.ruby-version(invoking something likervm use $(cat $working_dir/.ruby-version)). If the user requires a customized.rvmrcthey can wire in.ruby-versionthemselves (i.e.environment_id="$(cat .ruby-version)@gemset"). - rbenv: A modification tolibexec/rbenv-version-file to check for
.rbenv-versionand then.ruby-version. - rbfu: A modifcation tobin/rbfu to first check for
.rbfu-versionand then.ruby-version.
In all 3 cases, it seems reasonable to prefer an implementation-specific file over the generic version--no loss of default behavior.
Feedback? Ideas? Questions?
| 1.9.3-p125 |
| #!/usr/bin/env bash | |
| # This is an RVM Project .rvmrc file, used to automatically load the ruby | |
| # development environment upon cd'ing into the directory | |
| # First we specify our desired <ruby>[@<gemset>], the @gemset name is optional, | |
| # Only full ruby name is supported here, for short names use: | |
| # echo "rvm use 1.9.3" > .rvmrc | |
| environment_id="$(cat .rbenv-version)@myapp" | |
| # Uncomment the following lines if you want to verify rvm version per project | |
| # rvmrc_rvm_version="1.10.3" # 1.10.1 seams as a safe start | |
| # eval "$(echo ${rvm_version}.${rvmrc_rvm_version} | awk -F. '{print "[[ "$1*65536+$2*256+$3" -ge "$4*65536+$5*256+$6" ]]"}' )" || { | |
| # echo "This .rvmrc file requires at least RVM ${rvmrc_rvm_version}, aborting loading." | |
| # return 1 | |
| # } | |
| # First we attempt to load the desired environment directly from the environment | |
| # file. This is very fast and efficient compared to running through the entire | |
| # CLI and selector. If you want feedback on which environment was used then | |
| # insert the word 'use' after --create as this triggers verbose mode. | |
| if [[-d"${rvm_path:-$HOME/.rvm}/environments" | |
| &&-s"${rvm_path:-$HOME/.rvm}/environments/$environment_id" ]] | |
| then | |
| \."${rvm_path:-$HOME/.rvm}/environments/$environment_id" | |
| [[-s"${rvm_path:-$HOME/.rvm}/hooks/after_use" ]]&& | |
| \."${rvm_path:-$HOME/.rvm}/hooks/after_use"||true | |
| else | |
| # If the environment file has not yet been created, use the RVM CLI to select. | |
| rvm --create"$environment_id"|| { | |
| echo"Failed to create RVM environment '${environment_id}'." | |
| return 1 | |
| } | |
| fi |
trans commentedApr 12, 2012
Could someone explain to me why you would want to nail a project down to a single install of ruby anyway?
When I work on projects I use the default ruby I setup in my home config and that's it. CI testing checks the other versions.
@trans I agree with you most of the time, although I make an exception for Rails/Sinatra applications. Unless it's an OSS app (like GitLab, Errbit, etc.), I'm most likely targeting a Ruby version in production. If nothing else it's an additional piece of project documentation. Otherwise, yeah I love to targetalltherubies!
hmans commentedJun 27, 2012
FWIW, I've just tagged and releasedrbfu 0.3.0, probably the last 0.x version before I tag a 1.0.0 and have another go at courting the Homebrew guys to include the rbfu formula.
postmodern commentedDec 15, 2012
chruby 0.3.0 will support optional auto-switching, which will use the.ruby-version file. However, chruby will allow.ruby-version to contain sub-strings of the fully qualified Ruby name (ex:jruby orruby-1.9).
ku1ik commentedDec 15, 2012
@postmodern nice!
havenwood commentedDec 22, 2012
chruby 0.3.0 has been released, so chruby now supports .ruby-version as well. 🍰
postmodern commentedDec 27, 2012
@fnichol can we add a small section on the contents of.ruby-version. I think.ruby-version may contain a sub-string that is fuzzy-matched against available Rubies. This would allow developers to specifyjruby orruby-1.9, and avoid specifying the exact version.
mislav commentedDec 30, 2012
rbenv is going to support.ruby-version, but definitely without any fuzzy matching. Here's why I think fuzzy matching is a bad idea:
- Let's suppose I have 1.9.3-p0 installed.
- I put "ruby-1.9" to
.ruby-versionin my project and all is well. - After some time I install 1.9.3-p300 to try it out and suddenly all my projects marked with "ruby-1.9" automatically upgrade to it. Gems need to be reinstalled, native extensions need to be upgraded, etc. Nightmare.
One of the important reasons why we have version managers is to be precise about versions. rbenv is going to be precise. If you want cute shortcuts & aliases, you can always make symlinks.
@postmodern Cheers on getting 0.3.0 out the door, one more on board!
@mislav I can get behind the reasoning for this here and I largely agree with you for the samereasons I would commit aGemfile.lock to a web application (vs. a gem library).
It looks like the active branch for.ruby-version in rbenv is being tracked inrbenv/rbenv#302, looks pretty solid and complete to me.
cgriego commentedJan 23, 2013
I'd love to see Heroku adopt this emerging standard.
pedz commentedJan 26, 2013
My approach is to have a per project rc file. I call mine .prvmrc and it is simply sourced e.g. . .prvmrc (kept at the top directory of the project)
This way it can have any shell commands you want. Normally it sets PATH, GEM_HOME, and GEM_PATH but it can also set the postgresql database default, etc. It does not set PATH directly but rather calls some shell functions. So, the weight is a few rather small shell functions added to the shell's profile.
I also have my bundler put the gems and bin in the .bundle subdir of the project so the front of the path becomes the path to the directory plus .bundle/bin. e.g. PATH=/path/to/app/.bundle/bin:/usr/local/bin:/usr/bin:...
There are no shims involved. .bundle/bin is seeded with symlinks to the original commands and the symlinks are over written as the gems (e.g. rake) are updated into the local project.
smaboshe commentedMar 13, 2013
Is there a convention for comments in a .ruby-version file?
leomao10 commentedMar 16, 2013
@mpapis Does RVM currently support reading .ruby-version?
I realized you have a commit for this issuervm/rvm#786
But I just could not find the docs from rvm.io
rweng commentedMar 16, 2013
@leomao10 just tested w/ rvm 1.18.20 and it works
ootoovak commentedMar 20, 2013
Just a note. Seems like RVM 1.18.21 now generates two files whenrvm --create --ruby-version use ruby-1.9.3-p392@my_project is run. The files are.ruby-version and.ruby-gemset.
terlar commentedMar 23, 2013
fry (fish ruby switcher) is also supporting this if you enable auto-switching, it comes with fuzzy matching andruby- prefixed is matched against non-ruby prefixed rubies.
# Fuzzyruby-1.9 => 1.9.3-p3921.9 => 1.9.3-p392jruby-1.7 => jruby-1.7.3# Non-fuzzyruby-1.9.3-p392 => 1.9.3-p3921.9.3-p392 => 1.9.3-p392jruby-1.7.3 => jruby-1.7.3postmodern commentedApr 15, 2013
@terlar nice to see another Ruby switcher supporting fuzzy matching. Specifying the fully qualified version is over-kill in most cases.
blackxored commentedJul 31, 2013
Guys, :+1 now only - don't complicated any more, and I certainly don't like the idea of just saying "jruby", will break on updates for granted. ;)
mpapis commentedAug 10, 2013
RVM (head/1.22.0) now supports also.ruby-env for setting environment variables when entering project directory, more details here:https://rvm.io/workflow/projects
swrobel commentedAug 3, 2014
@fnichol Can this be updated with a clear spec for the agreed-upon.ruby-version file format since all of the version managers seem to link to this page like it provides a spec?
zw963 commentedOct 10, 2014
rbenv is not support specify2.1 in .ruby-version, But rvm can auto use the latest ruby version which match
2.1 serious.
e.g. if you have ruby 2.1.2 installed, and project root exist .ruby-version, content is2.1, rbenv is halted,
but rvm can auto use 2.1.2. it you install 2.1.3 with rvm, it auto use 2.1.3 too.
FranklinYu commentedOct 11, 2015
Some user not using MRI may hope that engine version can be specified, like
1.9jruby1.6.7However, I do not think it wise to save all the environment variables in this file. They should be in some separate file, says,.env. The.ruby-version should only specifies the Ruby version as named.
ktaragorn commentedDec 23, 2015
@mpapis Can we have fuzzy matching in RVM as well? "2.3.0" -> "2.3.0-preview2"? So that I dont have to keep changing the name as it matures. Was this removed recently? I swear it was working until a day or 2 ago. This is for both gemfile and .ruby-version
ktaragorn commentedDec 23, 2015
This is needed because withGemfile, Bundler checks againstRUBY_VERSION if it matches
Your Ruby version is 2.3.0, but your Gemfile specified 2.3.0-preview2Right now I have2.3.0-preview2 to make rvm happy in.ruby-version and 2.3.0 inGemfile to make bundler happy
FranklinYu commentedAug 15, 2016
@ktaragorn I guess you should specify the patch level with:patchlevel => 'preview2'.
It’s also possible to restrict the patchlevel of the Ruby used by doing the following:
ruby'1.9.3',:patchlevel=>'448'
so you can have the exact version in both.ruby-version andGemfile.
@mislav your explanation about fuzzy matching upsets me a little bit, developers are adults and they know how to deal with version problems, supporting fuzzy versions will allow teams to chose whatever fits theres needs, if "paranoid" people like you still want to be very careful about the version they use, they still have the possibility to force the exact version.
MartinNowak commentedNov 29, 2017
Regardinghttps://gist.github.com/fnichol/1912050#gistcomment-682506
If you want cute shortcuts & aliases, you can always make symlinks.
ln -s 2.3.5~/.rbenv/versions/2.3Is a clean and simple solution to alias an installed ruby version.
rbenv versions
* 2.3 (set by .ruby-version) 2.3.5What aboutasdf VM and its.tool-versions? e.g.
cat .tool-versions
postgres systemruby 2.7.5redis 6.0.8yarn 1.22.5nodejs 16.9.1andyw8 commentedJan 2, 2024
Specification for .ruby-version (rubygems discussion).