I've been using this technique in most of my Ruby projects lately where Ruby versions are required:
.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....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.
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:
.rvmrc and then .ruby-version (invoking something like rvm 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-version and then .ruby-version..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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4