A Common .ruby-version File For Ruby Projects (original) (raw)

Background

I've been using this technique in most of my Ruby projects lately where Ruby versions are required:

Create .rbenv-version containing the target Ruby using a definition name defined in 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, where the author is using a similar technique with .rbfu-version.

So...

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

Without a more thorough investigation (here be dragons?), the project-level updates might be:

rvm: A modification to scripts/functions/rvmrc to check for .rvmrc and then .ruby-version (invoking something like rvm use <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo stretchy="false">(</mo><mi>c</mi><mi>a</mi><mi>t</mi></mrow><annotation encoding="application/x-tex">(cat </annotation></semantics></math>(catworking_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 to check for .rbenv-version and then .ruby-version.
rbfu: A modifcation to bin/rbfu 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? Questions?