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?
@mislav your explanation about fuzzy matching upsets me a little bit, developers are adults and they know how to deal with version problems, supporting fuzzy versions will allow teams to chose whatever fits theres needs, if "paranoid" people like you still want to be very careful about the version they use, they still have the possibility to force the exact version.