Add file option to ruby method in Gemfile

[ngan]

Fixes #6742. Please read the original issue for full context.

You can now do this in your Gemfile:

ruby file: '.ruby-version'

[deivid-rodriguez]

Thanks!

The original specification by indirect seems better to me though? I think it could get confusing if ruby '3.1.0', file: '.ruby-version' ends up using a different ruby than 3.1.0? What the use case for the extra flexibility?

[ngan]

Thanks!

The original specification by indirect seems better to me though? I think it could get confusing if ruby '3.1.0', file: '.ruby-version' ends up using a different ruby than 3.1.0? What the use case for the extra flexibility?

@deivid-rodriguez yeah, I can't think of one that doesn't cause even more confusion 😅

I've updated the logic to raise an error if you provide both.

[martinemde]

I know @hsbt brought up something similar, but I'll ask anyway. Could ruby :file be a shortcut for the very most common filename of .ruby-version. 99% of all gemfiles will have ruby file: '.ruby-version' once this change is widely adopted.

[ngan]

Could ruby :file be a shortcut for the very most common filename of .ruby-version.

I personally think it's too much implicitness. Typing out .ruby-version (you only have to do it once) makes it very clear where it's coming from for new Ruby users. Similarly, source 'https://rubygems.org' is at the top of 99% of Gemfiles out there...but I'm guessing it's there for the same reason. 🤷

[martinemde]

One last thought: should we add ruby version: '3.2.2' for consistency? (please ignore this for this PR though, I think it's good to go)

[deivid-rodriguez]

Actually, this should be documented in the gemfile.5 man page. Can we add a note about the new option?

[ngan]

@deivid-rodriguez done!

[deivid-rodriguez]

Awesome! Rebased and squashed, and going in!

[jasnow]

Does this feature work with ruby 3.3.0.preview1?
I'm getting an error message: Your Ruby version is 3.3.0.preview1, but your Gemfile specified

[simi]

Does this feature work with ruby 3.3.0.preview1? I'm getting an error message: Your Ruby version is 3.3.0.preview1, but your Gemfile specified

It is not part of Ruby 3.3.0.preview1 per my understanding, but it was released in Bundler 2.4.19 version. Just ensure you have right version.

[jasnow]

This issue is "rvm list" shows "3.0.0.preview1" (period before preview1) where .ruby-versions and bundler want "-" before preview1. Now have a "fix".

[alec-c4]

What about support of asdf? Because they have slightly different syntax.

[simi]

What about support of asdf? Because they have slightly different syntax.

@alec-c4 support for .tool-versions was added at #6898

[alec-c4]

What about support of asdf? Because they have slightly different syntax.

@alec-c4 support for .tool-versions was added at #6898

Yay!!!!!! Such an awesome news!!!!

[pboling]

This doesn't quite work right.

[!] There was an error parsing `Gemfile`: Illformed requirement ["ruby 2.7.8\ndirenv 2.32.2\nmongodb 6.2.1"]. Bundler cannot continue.

 #  from /Volumes/🐉🩸/src/apps/counting_sheep/Gemfile:1
 #  -------------------------------------------
 >  ruby file: ".tool-versions"
 #  
 #  -------------------------------------------

where my .tool-versions file has:

ruby 2.7.8
direnv 2.32.2
mongodb 6.2.1

Alternatively with .ruby-version:

[!] There was an error parsing `Gemfile`: Illformed requirement ["ruby-2.7.8"]. Bundler cannot continue.

 #  from /Volumes/🐉🩸/src/apps/counting_sheep/Gemfile:1
 #  -------------------------------------------
 >  ruby file: ".ruby-version"
 #  
 #  -------------------------------------------

where my .ruby-version file has:

ruby-2.7.8

[hsbt]

@pboling Because we didn't backport #6898 into stable version yet.

[pboling]

The problem is Gem::Requirement.parse is not sufficient for either .ruby-version or .tool-versions, and the spec added in this PR is too mocky to detect the issue.

before { allow(Bundler).to receive(:read_file).with("foo").and_return("#{version}\n") }

[martinemde]

It seems we need better tests for this. Thank you for reporting.

[pboling]

You could argue that it is not mocky enough. 👍 Perhaps a test that mocks the parse result for each distinct "standard" (not-a-real-standard) format of .ruby-version.

3.1.2
ruby-3.1.2
3.1.2@gemset
ruby-3.1.2@gemset

Not sure if there is a comprehensive list anywhere of all the formats of .ruby-version as it is a loosely shared standard between the many Ruby version managers, but here is rvm's incomplete documentation:
https://rvm.io/workflow/projects#project-file-ruby-version

[martinemde]

I'm looking into fixing this now. FWIW this might be the original proposal for .ruby-version from 2012 and has received running updates along the way as things were decided.

I'm of two minds for this behavior. One the one hand, Bundler could be opinionated about the format. We could simply say that if you put something into .ruby-version that is not a simple version, then Bundler won't read it. (In other words, a Steve Jobs "Don't hold it that way")

On the other hand, this format is not up to bundler and has existed for a long time. It's used by rbenv, chruby, rvm and we have chosen to attempt to read asdf's format.

It's trivial to trim ruby- off the front and @gemset off the end, but if users of bundler can just tweak their .ruby-version file with no ill effect, then keeping this simple would also produce a narrowing of usage of .ruby-version, and dare I even say it, a standard format.

[pboling]

For those who rely on the @gemset to provide encapsulaiton between multiple installations on a single VPS, as I used to many years ago, not supporting it would mean they can't use the file: feature at all... but maybe that's not the end of the world? I do think that at minimum the ruby- can be stripped, because even those who are not using gemsets may be using it, and supporting it will prevent confused bug reports from users attempting to try out file: and having it blow up. I suppose the same could be said for supporting @gemset.

[martinemde]

Thanks for taking up this discussion and for making sure we solve this as well as possible.

For @gemset, I see that RVM documents that @gemset is not compatible with other version managers. They suggest that users should rely on the .ruby-gemset file for that feature. I feel good excluding that behavior since it's definitely non-standard and the work around is easy and recommended.

I am patching this to support removing ruby- since that seems to be fairly common. I'll update with a ticket number when I push. (#6954)

Also for jruby/truffleruby folks out there, you might end up with something like this (this is not a recommendation, but just pointing out that the engine options are allowed with the file option)

ruby file: ".ruby-version", engine: "jruby", engine_version: "9.4.3.0"

$ cat .ruby-version
3.1.4