fnichol · February 26, 2012 01:23 · Feb 26, 2012 · Feb 26, 2012 · Feb 26, 2012 · Feb 26, 2012
diff --git a/README.md b/README.md
@@ -1,4 +1,4 @@
-# .ruby-version Proposal
+# A Common .ruby-version File For Ruby Projects
 
 ## Background
 

diff --git a/README.md b/README.md
@@ -7,7 +7,7 @@ I've been using this technique in most of my Ruby projects lately where Ruby ver
 * Create `.rbenv-version` containing the target Ruby using a definition name defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build) (example below). These strings are a proper subset of RVM Ruby string names so far...
 * Create `.rvmrc` (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id=` line to fetch the Ruby version from `.rbenv-version` (example below).
 
-Today I learned about another Ruby manager, [rbfu](https://github.com/hmans/rbfu)), where the author is using a similar technique with `.rbfu-version`.
+Today I learned about another Ruby manager, [rbfu](https://github.com/hmans/rbfu), where the author is using a similar technique with `.rbfu-version`.
 
 ## So...
 

diff --git a/README.md b/README.md
@@ -15,14 +15,14 @@ What if we had an ecosystem of fabulous Ruby managers that all understood the se
 
 ## Perhaps We Can
 
-Without a more thorough investigation (here be dragons?), all that would be required at a code level is:
+Without a more thorough investigation (here be dragons?), the project-level updates might be:
 
-* **rvm:** A modification to [scripts/functions/rvmrc](https://github.com/wayneeseguin/rvm/blob/master/scripts/functions/rvmrc#L370-392) to check for `.rvmrc` and then `.ruby-version` (invoking something like `rvm use $(cat $working_dir/.ruby-version)`). If the user requires a customized `.rvmrc` file then they can wire in `.ruby-version` themselves (i.e. `environment_id="$(cat .ruby-version)@gemset"`).
+* **rvm:** A modification to [scripts/functions/rvmrc](https://github.com/wayneeseguin/rvm/blob/master/scripts/functions/rvmrc#L370-392) to check for `.rvmrc` and then `.ruby-version` (invoking something like `rvm use $(cat $working_dir/.ruby-version)`). If the user requires a customized `.rvmrc` they can wire in `.ruby-version` themselves (i.e. `environment_id="$(cat .ruby-version)@gemset"`).
 * **rbenv:** A modification to [libexec/rbenv-version-file](https://github.com/sstephenson/rbenv/blob/master/libexec/rbenv-version-file) to check for `.rbenv-version` and then `.ruby-version`.
 * **rbfu:** A modifcation to [bin/rbfu](https://github.com/hmans/rbfu/blob/master/bin/rbfu#L42-44) to first check for `.rbfu-version` and 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.
 
 ## So?
 
-Feedback? Ideas?
+Feedback? Ideas? Questions?
diff --git a/README.md b/README.md
@@ -2,12 +2,12 @@
 
 ## Background
 
-In an attempt at supporting maximum love of the Rubies I've been using this technique in most of my Ruby projects (such as Rails/Sinatra applications, Chef repos, etc.):
+I've been using this technique in most of my Ruby projects lately where Ruby versions are required:
 
-* Create an `.rbenv-version` file containing the target Ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build) (example below). These strings are a proper subset of RVM Ruby string names so far...
-* Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version` (example below).
+* Create `.rbenv-version` containing the target Ruby using a definition name defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build) (example below). These strings are a proper subset of RVM Ruby string names so far...
+* Create `.rvmrc` (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id=` line to fetch the Ruby version from `.rbenv-version` (example below).
 
-When I heard about another Ruby manager ([rbfu](https://github.com/hmans/rbfu)), I saw the author was using a similar selector with a `.rbfu-version` file.
+Today I learned about another Ruby manager, [rbfu](https://github.com/hmans/rbfu)), where the author is using a similar technique with `.rbfu-version`.
 
 ## So...
 

diff --git a/README.md b/README.md
@@ -21,4 +21,8 @@ Without a more thorough investigation (here be dragons?), all that would be requ
 * **rbenv:** A modification to [libexec/rbenv-version-file](https://github.com/sstephenson/rbenv/blob/master/libexec/rbenv-version-file) to check for `.rbenv-version` and then `.ruby-version`.
 * **rbfu:** A modifcation to [bin/rbfu](https://github.com/hmans/rbfu/blob/master/bin/rbfu#L42-44) to first check for `.rbfu-version` and 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.
+In all 3 cases, it seems reasonable to prefer an implementation-specific file over the generic version--no loss of default behavior.
+
+## So?
+
+Feedback? Ideas?
diff --git a/README.md b/README.md
@@ -11,7 +11,7 @@ When I heard about another Ruby manager ([rbfu](https://github.com/hmans/rbfu)),
 
 ## So...
 
-What if we had an ecosystem of fabulous Ruby managers that would 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.
+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.
 
 ## Perhaps We Can
 

diff --git a/README.md b/README.md
@@ -7,7 +7,7 @@ In an attempt at supporting maximum love of the Rubies I've been using this tech
 * Create an `.rbenv-version` file containing the target Ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build) (example below). These strings are a proper subset of RVM Ruby string names so far...
 * Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version` (example below).
 
-When I heard about another Ruby manager ((rbfu)[https://github.com/hmans/rbfu]), I saw the author was using a similar selector with a `.rbfu-version` file.
+When I heard about another Ruby manager ([rbfu](https://github.com/hmans/rbfu)), I saw the author was using a similar selector with a `.rbfu-version` file.
 
 ## So...
 

diff --git a/README.md b/README.md
@@ -4,8 +4,8 @@
 
 In an attempt at supporting maximum love of the Rubies I've been using this technique in most of my Ruby projects (such as Rails/Sinatra applications, Chef repos, etc.):
 
-* Create an `.rbenv-version` file containing the target Ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build). These strings are a proper subset of RVM Ruby string names so far...
-* Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version`.
+* Create an `.rbenv-version` file containing the target Ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build) (example below). These strings are a proper subset of RVM Ruby string names so far...
+* Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version` (example below).
 
 When I heard about another Ruby manager ((rbfu)[https://github.com/hmans/rbfu]), I saw the author was using a similar selector with a `.rbfu-version` file.
 

diff --git a/README.md b/README.md
@@ -2,16 +2,23 @@
 
 ## Background
 
-In an attempt at supporting all the Ruby love I've been using this technique in most of my Ruby projects (such as Rails/Sinatra applications, Chef repos, etc.):
+In an attempt at supporting maximum love of the Rubies I've been using this technique in most of my Ruby projects (such as Rails/Sinatra applications, Chef repos, etc.):
 
-* Create an `.rbenv-version` file containing the target ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build). These strings are a proper subset of RVM Ruby names so far...
+* Create an `.rbenv-version` file containing the target Ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build). These strings are a proper subset of RVM Ruby string names so far...
 * Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version`.
 
-When I heard about another Ruby manager ((rbfu)[https://github.com/hmans/rbfu]), I saw they were using a similar selector with a `.rbfu-version` file.
+When I heard about another Ruby manager ((rbfu)[https://github.com/hmans/rbfu]), I saw the author was using a similar selector with a `.rbfu-version` file.
 
 ## So...
 
-What if we had an ecosystem of fabulous Ruby managers that would all understand the contents and semantics of a generic dotfile such as `.ruby-version`?
+What if we had an ecosystem of fabulous Ruby managers that would 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.
 
-* **rbenv:** A modification to [libexec/rbenv-version-file](https://github.com/sstephenson/rbenv/blob/master/libexec/rbenv-version-file) to check for `.rbenv-version` and then `.ruby-version` (it seems reasonable to prefer an implementation-specific file over the generic version)
-* **rvm:** A modification to [scripts/functions/rvmrc](https://github.com/wayneeseguin/rvm/blob/master/scripts/functions/rvmrc#L370-392) to check for `.rvmrc` and then `.ruby-version` (invoking something like `rvm use $(cat $working_dir/.ruby-version)`). If the user requires a customized `.rvmrc` file then they can wire in `.ruby-version` themselves (i.e. `environment_id="$(cat .ruby-version)@gemset"`).
+## Perhaps We Can
+
+Without a more thorough investigation (here be dragons?), all that would be required at a code level is:
+
+* **rvm:** A modification to [scripts/functions/rvmrc](https://github.com/wayneeseguin/rvm/blob/master/scripts/functions/rvmrc#L370-392) to check for `.rvmrc` and then `.ruby-version` (invoking something like `rvm use $(cat $working_dir/.ruby-version)`). If the user requires a customized `.rvmrc` file then they can wire in `.ruby-version` themselves (i.e. `environment_id="$(cat .ruby-version)@gemset"`).
+* **rbenv:** A modification to [libexec/rbenv-version-file](https://github.com/sstephenson/rbenv/blob/master/libexec/rbenv-version-file) to check for `.rbenv-version` and then `.ruby-version`.
+* **rbfu:** A modifcation to [bin/rbfu](https://github.com/hmans/rbfu/blob/master/bin/rbfu#L42-44) to first check for `.rbfu-version` and 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.
diff --git a/README.md b/README.md
@@ -11,4 +11,7 @@ When I heard about another Ruby manager ((rbfu)[https://github.com/hmans/rbfu]),
 
 ## So...
 
-What if we had an ecosystem of fabulous Ruby managers that would all understand the contents and semantics of a generic dotfile such as `.ruby-version`?
+What if we had an ecosystem of fabulous Ruby managers that would all understand the contents and semantics of a generic dotfile such as `.ruby-version`?
+
+* **rbenv:** A modification to [libexec/rbenv-version-file](https://github.com/sstephenson/rbenv/blob/master/libexec/rbenv-version-file) to check for `.rbenv-version` and then `.ruby-version` (it seems reasonable to prefer an implementation-specific file over the generic version)
+* **rvm:** A modification to [scripts/functions/rvmrc](https://github.com/wayneeseguin/rvm/blob/master/scripts/functions/rvmrc#L370-392) to check for `.rvmrc` and then `.ruby-version` (invoking something like `rvm use $(cat $working_dir/.ruby-version)`). If the user requires a customized `.rvmrc` file then they can wire in `.ruby-version` themselves (i.e. `environment_id="$(cat .ruby-version)@gemset"`).
diff --git a/README.md b/README.md
@@ -5,4 +5,10 @@
 In an attempt at supporting all the Ruby love I've been using this technique in most of my Ruby projects (such as Rails/Sinatra applications, Chef repos, etc.):
 
 * Create an `.rbenv-version` file containing the target ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build). These strings are a proper subset of RVM Ruby names so far...
-* Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version`.
+* Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version`.
+
+When I heard about another Ruby manager ((rbfu)[https://github.com/hmans/rbfu]), I saw they were using a similar selector with a `.rbfu-version` file.
+
+## So...
+
+What if we had an ecosystem of fabulous Ruby managers that would all understand the contents and semantics of a generic dotfile such as `.ruby-version`?
diff --git a/.rbenv-version → Sample.rbenv-version b/.rbenv-version → Sample.rbenv-version
diff --git a/.rvmrc → Sample.rvmrc b/.rvmrc → Sample.rvmrc
diff --git a/README.md b/README.md
@@ -0,0 +1,8 @@
+# .ruby-version Proposal
+
+## Background
+
+In an attempt at supporting all the Ruby love I've been using this technique in most of my Ruby projects (such as Rails/Sinatra applications, Chef repos, etc.):
+
+* Create an `.rbenv-version` file containing the target ruby using the definition names defined in [ruby-build](https://github.com/sstephenson/ruby-build/tree/master/share/ruby-build). These strings are a proper subset of RVM Ruby names so far...
+* Create an `.rvmrc` file (with `rvm --create --rvmrc "1.9.3@myapp"`) and edit the `environment_id` line to fetch the Ruby version from `.rbenv-version`.
diff --git a/.rbenv-version b/.rbenv-version
@@ -0,0 +1 @@
+1.9.3-p125
diff --git a/.rvmrc b/.rvmrc
@@ -0,0 +1,34 @@
+#!/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