Feature: Use ruby version specified in Gemfile

[askehansen]

Since heroku looks in the Gemfile for a ruby version, it would be convenient if chruby did the same

[postmodern]

This is a bundler feature. Also, no easy way to extract the ruby version, since the Gemfile is Ruby code itself.

[adamstac]

That's a bummer. I'm surprised more people haven't mentioned this more here.

Using the Gemfile to declare the Ruby version seems more DRY than creating a .ruby-version file just to set the Ruby version.

[postmodern]

While I see the value in using the Gemfile to assert a required ruby versions/engine, .ruby-version is more intended to select the desired ruby version or engine, mainly for development. Heroku appears to be the only one who uses the Gemfile to activate the desired version/engine. The only time I've specified a ruby version/engine, was for jruby/rbx specific dependencies.

[marnen]

@postmodern:

Heroku appears to be the only one who uses the Gemfile to activate the desired version/engine.

False. RVM does this too, and it's very convenient. Right now it's the big thing I'm missing in chruby as compared to RVM.

[postmodern]

@marnen ah apparently RVM1 greps the Gemfile.

[marnen]

Makes sense. So does the equivalent rbenv plugin, I believe.

[adamstac]

Yes @postmodern, RVM does.

This is a print out from terminal when I cd into a directory with a Gemfile and RVM.

adamstacoviak@AS-rMBP [10:51] [~]
-> % cd changelog/nightly
RVM used your Gemfile for selecting Ruby, it is all fine - Heroku does that too,
you can ignore these warnings with 'rvm rvmrc warning ignore /Users/adamstacoviak/Code/changelog/nightly/Gemfile'.
To ignore the warning for all files run 'rvm rvmrc warning ignore allGemfiles'.

[deivid-rodriguez]

Is this a final decision? It's hard to choose between heroku and chruby.

[postmodern]

@deivid-rodriguez you could pull .ruby-version into the Gemfile (ruby File.read('.ruby-version').chomp). Ideally, I wish heroku or bundler would support loading .ruby-version for us.

At work, we just use the default ruby and also set the X.Y version in .ruby-version.

[deivid-rodriguez]

@postmodern Thanks.

[simi]

@postmodern IMHO Gemfile.lock locked Ruby auto-switch will make sense today. Would be PR welcomed?

[postmodern]

@postmodern IMHO Gemfile.lock locked Ruby auto-switch will make sense today. Would be PR welcomed?

It appears that Bundler has added support for specifying a version constraint in the Gemfile (ex: ruby '>= 3.0.0'), but it still generates a Gemfile.lock containing the current ruby version if the current ruby version satisfies the Gemfile ruby version requirement.

Gemfile

source 'https://rubygems.org/'

ruby '> 3.0'

Gemfile.lock

...

RUBY VERSION
   ruby 3.1.2p20

BUNDLED WITH
   2.3.17

While we could in theory extract the ruby version from Gemfile.lock (and remove the pXYZ suffix), I still feel like .ruby-version is a better place to specify which ruby, version, or version-family (ex: ruby-3.0) one would like chruby to auto-switch to for that project. Also, there's the edge-case where a project contains both a .ruby-version file and a Gemfile.lock with a RUBY VERSION value defined; which should take precedence?

Maybe in the future when I add support for registering multiple chruby auto-functions this could be supported?

[simi]

It appears that Bundler has added support for specifying a version constraint in the Gemfile (ex: ruby '>= 3.0.0'), but it still generates a Gemfile.lock containing the current ruby version if the current ruby version satisfies the Gemfile ruby version requirement.

AFAIK that's on purpose, there should be only 1 unique way to evaluate Gemfile.lock. Locking to open constraint would break this requirement. It seems to me this feature is actually misused. For "project" like Gemfile you should specify full Ruby version and for "library" like Gemfile you should use gemspec and required_ruby_version.

We can remove patch part of the version, that's good idea. I think it was officially abandoned.

My motivation in here is to prevent multiple files to describe your bundle and also to prevent need for "programming" in Gemfile (like reading file https://github.com/rails/rails/pull/46528) at all. Since that way you have .ruby-version most likely specifying full Ruby version which is on the fly evaluated in Gemfile using File.read to just lock it into Gemfile.lock again. That way info about Ruby version is actually stored twice in two files. Why to not store it only int he Gemfile.lock and rely on that?