Not sure about all pros/cons for this but it seems configuring ruby version in two different files (Gemfile for Heroku and bundler / .ruby-version for rbenv) seems like one file too many.
I would expect rbenv to scan Gemfile for ruby version unless a .ruby-version file was present.
Makes sense?
there's a plugin that does this: https://github.com/aripollak/rbenv-bundler-ruby-version
But it's kind of buggy. The gemfile-specified ruby isn't respected when interrogating rbenv version which makes most PS1 statuses misleading.
I don't think it plays well with rbenv-binstubs, either.
Sorry for late reply. Yes, this is plugin material. The plugin is probably buggy because there's no easy way to hook into version lookup process. I will think about whether we can make this hookable.
However, I don't see it as a huge problem if there is both a .ruby-version and ruby statement in the Gemfile. It doesn't seem like such a huge developer pain that we absolutely must solve.
I don't believe that having both .ruby-version and Gemfile ruby directive is the problem. But rather, the desire to _only_ use the Gemfile. I still think this belongs as a plugin, so this issue could probably be closed.
But I think rbenv could make this hookable. To that end, I've been playing around with creating version-name and version-origin hooks. As a test case, I've been using a modified version of the rbenv-bundler-ruby-version plugin as the consumer of those hooks. It's working quite well and I hope to have a PR ready tomorrow, where discussion can continue.
As a test case, I've been using a modified version of the rbenv-bundler-ruby-version plugin as the consumer of those hooks
Sounds good, thanks!
@jasonkarns is correct, we would like to only use the Gemfile. But in case both would be available it seemed likely most people would expect the .ruby-version file to take precedence.
Knew about the plugin but wanted to avoid forcing everyone on a big dev-team to install it.
Considering this is becoming the de-facto way of specifying a ruby-version for a project it seems sensible for rbenv to use it by default. Principle of least surprise, convention over configuration and all that...
@mislav PR #739 opened for discussion
@dbackeus you've probably already seen this, too. but here's the original issue/comments/decision regarding Gemfile #223.
Thanks for the issue link, I hadn't seen it actually. Guess this is sort of a duplicate then. But maybe feels more relevant now that more or less everyone specifies their ruby version in the Gemfile?
Regarding a mention of not wanting to couple rbenv "even to bundler"... I guess bundler is now getting integrated in rubygems, which is already integrated in ruby. So maybe doesn't seem like so much of a stretch anymore?
@dbackeus Yep, not such a stretch anymore. However, I feel that this is still plugin material. Moreover, if we tweak rbenv to allow plugin hooks for this, then other people could come up with even cleverer version selection. Closing this in favor of @jasonkarns's PR.
I wish this decision would be revisited now that Bundler is the de facto dependency manager for Ruby. Shouldn鈥檛 simplicity for the end user trump simplicity of the internals of the tool? The fact that you have to specify the same Ruby version in two separate places just seems inelegant and unnecessary to me at this point鈥攖he .ruby-version file has become superfluous. I understand the argument for keeping this functionality in a plugin, but a plugin is a poor solution in a team environment. Rbenv has become such an indispensable part of so many people鈥檚 Ruby toolboxes that I think it warrants slightly tighter integration with other crucial pieces like Bundler 馃檪
I agree with @codyrobbins, maybe it is time to revisit this issue.
My workplace is already in the process of migrating from .ruby-version to Gemfile.
I believe that not having support for versions specified through Gemfiles will push users towards switching to rvm because it works "out of the box" and therefore is easier to use and recommend in a team environment.
After reading @jeppester comment, I wanted to give an update regarding my situation with rbenv.
The lack of support for this feature has been one of the major reasons why I changed recently to rvm and have been recommending it instead of rbenv.
I really hope that you guys reconsider the decision in the near future.
Just wanted to leave a note here for posterity: since a Gemfile is Ruby, you can always parse a ruby-version file to determine the version for the Gemfile:
ruby File.read('.ruby-version').strip
Most helpful comment
I agree with @codyrobbins, maybe it is time to revisit this issue.
My workplace is already in the process of migrating from
.ruby-versiontoGemfile.