It would be nice if ruby versions could also be specified with a .ruby-version file.
Most ruby version managers support this convention now.
What would you want to happen when there is a ruby version file and a different version specified in the buildpack?
What are the advantages of multiple ways to specify Ruby versions? This would be confusing to customers.
RVM already has support for declaring ruby version in the Gemfile. It would be easier for the community to standardize on one canonical source, rather than creating pseudo-standard factions. .rvmrc and .rb-env files aren't supposed to be standards and are not recommend to be checked into source, they're an implementation detail.
Since everyone already has a Gemfile, and that Gemfile is used to declare versions of dependencies it stands to reason that you would declare your version of Ruby in your Gemfile. If version managers don't support declaring Ruby version in Gemfile, issues should be opened on those projects, and we can work on integration.
Thanks for opening an issue in the buildpack, but I think this is outside of our scope.
RVM now displays an error if you cd into a folder using a .rvmrc file, instead suggesting that you use these two files:
.ruby-version # which rbenv recognizes
.ruby-gemset # ignored by everyone but RVM
Both containing simple strings instead of shell scripts.
I would love to be able to keep ruby versions out of my Gemfiles, and the difficulty of implementation has gone down considerably
I wrote this down about .ruby-version. https://gist.github.com/hone/417819ea3bf1bfea2333. I even wrote a prototype of this in a branch over the weekend, see the ruby_versions branch. As the current way .ruby-version stands though, it'd be hard to support it except for MRI.
I think it would be good to support this. This gets around the problem in #100. We can check for ruby-version file first and default to getting platform out from bundler.
In my dream world bundler would generate a ruby-version file automatically so that we could eventually drop the default version support (i.e. rails new && bundle install would be enough to explicitly tell Heroku what Ruby version you want). This workflow would still be difficult for teams as it would enforce that they all have to be on the same patch level (but maybe they should be).
@hone is your branch in a PR-able state?
I'm closing this for now. We aren't likely to support this in the near future, but still open to more discussion on it.
Hi @hone sorry for bringing this issue up again.. but there have been developments in bundle that might change things.
This PR have been merged to the 2.0-dev branch, so is not ready for now, but it shows how bundler is going let you handle ruby versions in the future using .ruby-version file. https://github.com/bundler/bundler/pull/4036/files
Do you think that this might change the position on how this heroku buildpack choose the ruby version?
We use whatever bundle ruby gives us. If bundler wants to support .ruby-version and give us a valid result we'll use it.
I finally ended up creating a buildpack that can be used before heroku-buildpack-ruby that injects the version from the .ruby-version into the Gemfile It also support versions without patch.
Will see what the future brings... :)