I've been using this technique in most of my Ruby projects lately where Ruby versions are required:
.rbenv-versioncontaining 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...
rvm --create --rvmrc "1.9.3@myapp") and edit the
environment_id=line to fetch the Ruby version from
Today I learned about another Ruby manager, rbfu, where the author is using a similar technique with
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 to scripts/functions/rvmrc to check for
.ruby-version(invoking something like
rvm use $(cat $working_dir/.ruby-version)). If the user requires a customized
.rvmrcthey can wire in
rbenv: A modification to libexec/rbenv-version-file to check for
rbfu: A modifcation to bin/rbfu to first check for
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?