A Common .ruby-version File For Ruby Projects about heroku-buildpack-ruby HOT 11 CLOSED

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.

from heroku-buildpack-ruby.

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 🐱

from heroku-buildpack-ruby.

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.
https://github.com/platanus/heroku-buildpack-ruby-version

Will see what the future brings... :)

from heroku-buildpack-ruby.

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.

from heroku-buildpack-ruby.

My logic goes something like this:

When someone puts a ruby statement in a Gemfile or adds a .ruby-version file to a repo this person intends the code to be run with that particular version of ruby. This someone would usually be the developer of the code and can be expected to understand his/her own actions (adding a version requirement).

I understand that this introduces a second way to do essentially the same thing. But the important thing here is to reduce the differences between dev en ops. So when some team use ruby-version-X during development then that version should be run by Heroku (not counting patch levels).

Anyways, I think it would make things simpler on the developers end as most of us use a version manager and most of us don't want to declare this version twice (and remember to keep these in sync).

On 05 Feb 2013, at 17:56, Richard Schneeman [email protected] wrote:

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.

—
Reply to this email directly or view it on GitHub.

from heroku-buildpack-ruby.

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.

from heroku-buildpack-ruby.

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?

from heroku-buildpack-ruby.

Yeah, but I'm unsure we should support two methods of doing this. Also, my
implementation isn't like the others since I've built it around how I think
the .ruby-version spec should be, not that there is one. The current one
is lacking. This would also require us to change all of our docs if we
decide to do this.

On Wed, Sep 25, 2013 at 1:14 PM, Richard Schneeman <[email protected]

wrote:

I think it would be good to support this. This gets around the problem in
#100 #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 https://github.com/hone is your branch in a PR-able state?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-25106448
.

from heroku-buildpack-ruby.

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.

from heroku-buildpack-ruby.

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?

from heroku-buildpack-ruby.

We use whatever bundle ruby gives us. If bundler wants to support .ruby-version and give us a valid result we'll use it.

from heroku-buildpack-ruby.