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
(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 to scripts/functions/rvmrc to check for
.rvmrc
and then.ruby-version
(invoking something likervm 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 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.
Feedback? Ideas? Questions?
rbenv is going to support
.ruby-version
, but definitely without any fuzzy matching. Here's why I think fuzzy matching is a bad idea:.ruby-version
in my project and all is well.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.