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?
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.