A Common .ruby-version File For Ruby Projects #63

Closed
fd opened this Issue Feb 4, 2013 · 11 comments

Comments

Projects
None yet
5 participants
@fd

fd commented Feb 4, 2013

It would be nice if ruby versions could also be specified with a .ruby-version file.
Most ruby version managers support this convention now.

See: https://gist.github.com/1912050

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Feb 5, 2013

Contributor

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.

Contributor

schneems commented Feb 5, 2013

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.

@fd

This comment has been minimized.

Show comment
Hide comment
@fd

fd Feb 5, 2013

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 notifications@github.com 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.

fd commented Feb 5, 2013

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 notifications@github.com 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.

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Feb 5, 2013

Contributor

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.

Contributor

schneems commented Feb 5, 2013

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.

@schneems schneems closed this Feb 5, 2013

@schneems schneems reopened this Feb 5, 2013

@seanlinsley

This comment has been minimized.

Show comment
Hide comment
@seanlinsley

seanlinsley Jun 7, 2013

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 🐱

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 🐱

@hone

This comment has been minimized.

Show comment
Hide comment
@hone

hone Jul 22, 2013

Member

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.

Member

hone commented Jul 22, 2013

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.

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Sep 25, 2013

Contributor

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?

Contributor

schneems commented Sep 25, 2013

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?

@hone

This comment has been minimized.

Show comment
Hide comment
@hone

hone Sep 25, 2013

Member

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 <notifications@github.com

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/heroku/heroku-buildpack-ruby/issues/63#issuecomment-25106448
.

Member

hone commented Sep 25, 2013

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 <notifications@github.com

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/heroku/heroku-buildpack-ruby/issues/63#issuecomment-25106448
.

@hone

This comment has been minimized.

Show comment
Hide comment
@hone

hone Mar 11, 2014

Member

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.

Member

hone commented Mar 11, 2014

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.

@hone hone closed this Mar 11, 2014

@pimpin pimpin referenced this issue in kandanapp/kandan May 11, 2014

Closed

Specify ruby version 1.9.3 in Gemfile #356

@blackjid

This comment has been minimized.

Show comment
Hide comment
@blackjid

blackjid Jan 24, 2016

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?

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?

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Jan 28, 2016

Contributor

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

Contributor

schneems commented Jan 28, 2016

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

@blackjid

This comment has been minimized.

Show comment
Hide comment
@blackjid

blackjid Jan 30, 2016

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... :)

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... :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment