ruby should support ">= 2.0.0" #2845

Closed
grosser opened this Issue Jan 28, 2014 · 13 comments

Comments

Projects
None yet
5 participants
Contributor

grosser commented Jan 28, 2014

I want to make our bundle fail if run on an old ruby version (newer versions are ok though)
tried using:

ruby ">= 2.0.0"

got this :)
Your Ruby version is 2.0.0, but your Gemfile specified >= 2.0.0

Owner

indirect commented Jan 30, 2014

Ruby doesn't support version specifiers, only specific versions. Someday it would be nice to support version specifiers and locked ruby versions.

On Tue, Jan 28, 2014 at 11:41 AM, Michael Grosser
notifications@github.com wrote:

I want to make our bundle fail if run on an old ruby version (newer versions are ok though)
tried using:

ruby ">= 2.0.0"

got this :)

Your Ruby version is 2.0.0, but your Gemfile specified >= 2.0.0

Reply to this email directly or view it on GitHub:
#2845

indirect added this to the 2.0 milestone Feb 6, 2014

RubyGems currently supports version specifiers in required_ruby_version through use of Gem::Version by appending patch level as a fourth digit on the version. Is there a reason this same mechanism couldn't be used by Bundler?

I'd be happy to provide a patch unless there's a reason not to use this same mechanism. I'd also be interested in doing this so that using gemspec in a Gemfile could also consider required_ruby_version if specified by the gemspec.

Owner

indirect commented Feb 16, 2014

Patch levels have been dropped as of Ruby 2.1. That's not the blocker. The blocker is that allowing version specifiers means we need to add the actual ruby version to the lock file, add some way to "update" the locked version to match the currently running version, and then release it in Bundler 2.0 because changing the lock format breaks backwards compatibility.

On Sun, Feb 16, 2014 at 11:47 AM, Joshua Ballanco
notifications@github.com wrote:

RubyGems currently supports version specifiers in required_ruby_version through use of Gem::Version by appending patch level as a fourth digit on the version. Is there a reason this same mechanism couldn't be used by Bundler?

I'd be happy to provide a patch unless there's a reason not to use this same mechanism. I'd also be interested in doing this so that using gemspec in a Gemfile could also consider required_ruby_version if specified by the gemspec.

Reply to this email directly or view it on GitHub:
#2845 (comment)

Right, I was more referring to the fact that RubyGems has already solved the problem of doing operator-based comparison of Ruby versions (as opposed to exact matching, like Bundler does currently).

Regarding the lock file, since Bundler currently doesn't store any information about Ruby version in the lock file, but instead reads the version from the Gemfile each time, it seems to me that we could add operator-based version matching in a backwards compatible manner. All that would have to change is how Bundler's ruby_version is constructed and compared.

I agree that eventually it would be a good idea to have the version stored in the lock file, but as @indirect point's out this would have to wait for 2.0. In the mean time, though, I see no reason why we can't just extend the functionality that already exists.

Owner

indirect commented Feb 16, 2014

I am definitely aware that Rubygems knows how to handle version requirements, as Bundler uses Gem::Requirement extensively. It is a deliberate choice to only allow a single Ruby version to be specified.

A range without a locked Ruby version is useless for deployment, which requires a single version. Additionally, a range without a locked Ruby version really tells you nothing about whether the application actually works with the entire range. The entire point of a lock is to give you a single reproducible set of versions (and that includes Ruby version, because they are wildly incompatible).

In conclusion, I don't think it makes sense to support Ruby version ranges without a locked Ruby version.

Ok, I can see that point of view. I'm still not crazy about the current situation, but I can understand the desire to wait for the full feature to be implemented.

Which brings me to the question: has their been any progress along these lines? If I was wanting to lend a hand, is there someone coordinating work in this area? From the bit of code-sluthing that I've done, it seems like the main point of contention will be that RubyGems handles version ranges for Ruby, but only seems to have rudimentary support for engine and engine version, while the reverse is true for Bundler.

I'm guessing the desired solution would be to meld these two feature sets?

Owner

indirect commented Feb 16, 2014

How is this related to Rubygems? What exactly is it about the current situation that makes you unhappy?

Adding support is not really complicated, for what it's worth — add the ruby version to the lock file, check that the running ruby meets the Gemfile requirement, update the lock when bundle install is run, make sure the lock version is running in deployment mode.

My main qualm is that using gemspec in my Gemfile doesn't use the required_ruby_version that I've set in the Gem spec, meaning that I have to specify what Ruby version to use in two places.

The reason I brought up RubyGems is that Bundler's RubyVersion class encapsulates both version and engine info, but RubyGems just uses their Requirement class (which has no way to specify a Ruby engine) to deal with Ruby versions. That said, I did find the Gem::RequestSet::GemDependencyAPI class in RubyGems that looks as if the RubyGems project is at least considering accounting for different engines.

I wonder if a single solution for both projects would be desirable? /cc @drbrain

Owner

indirect commented Feb 19, 2014

The ruby Gemfile DSL is for applications, to allow reliable deployment. It’s not expected or recommended that you set it for gems. It does support engine version inherently, but again, for applications, to allow reliable deployments. It’s not for gems, which should ideally work across multiple ruby versions and engines.

On Feb 19, 2014, at 9:12 PM, Joshua Ballanco notifications@github.com wrote:

My main qualm is that using gemspec in my Gemfile doesn't use the required_ruby_version that I've set in the Gem spec, meaning that I have to specify what Ruby version to use in two places.

The reason I brought up RubyGems is that Bundler's RubyVersion class encapsulates both version and engine info, but RubyGems just uses their Requirement class, which has no way to specify a Ruby engine, to deal with Ruby versions. That said, I did find the Gem::RequestSet::GemDependencyAPI class in RubyGems that looks as if the RubyGems project is at least considering accounting for different engines.

I wonder if a single solution for both projects would be desirable? /cc @drbrain


Reply to this email directly or view it on GitHub.

I agree that ideally gems would work across versions and engines, but that's not always possible. Whether it's a JRuby-specific version of a C extension-based gem or a gem that requires features only found in 2.0 or 2.1, there are cases where gems will have limited deployability. If this weren't the case, then RubyGems wouldn't have required_ruby_version.

As for why it is important to have this setting in Bundler, I agree that Bundler is primarily useful for deploying code. But isn't running a gem's test suite on a CI server a kind of a deployment? At least, that's the exact scenario that brought me to this bug.

Owner

indirect commented Feb 19, 2014

having a CI server for libraries is kind of the exact opposite of deployment. :) applications and deployment are about having a single set of versions for everything that is blessed and working and used in production. gems (hopefully) never work with a single blessed version of ruby. if they do, then the ruby option is a good one. ruby in the gemfile isn't intended to act as a list of version the gem works with. that is what required_ruby_version is for.

all that to say, it's not repetition, they have different purposes, please don't confuse them. :)

On Thu, Feb 20, 2014 at 7:20 AM, Joshua Ballanco notifications@github.com
wrote:

I agree that ideally gems would work across versions and engines, but that's not always possible. Whether it's a JRuby-specific version of a C extension-based gem or a gem that requires features only found in 2.0 or 2.1, there are cases where gems will have limited deployability. If this weren't the case, then RubyGems wouldn't have required_ruby_version.

As for why it is important to have this setting in Bundler, I agree that Bundler is primarily useful for deploying code. But isn't running a gem's test suite on a CI server a kind of a deployment? At least, that's the exact scenario that brought me to this bug.

Reply to this email directly or view it on GitHub:
#2845 (comment)

Contributor

drbrain commented Feb 20, 2014

@jballanc I think what you want requires the new index work that @indirect is performing separately from rubygems and bundler. At this time neither can install gems based on the require_ruby_version field as it is not reported in the index.

@drbrain Thanks for the pointer. I'll be sure to keep an eye on that project. Also thank you, @indirect, for the discussion. It's given me a better idea for what I'm actually looking for. At this point, though, I'll keep exploring that idea independently and report back if/when I have something to show for it.

Who828 closed this Sep 7, 2014

begedin referenced this issue in coderly/code Jul 20, 2015

Closed

Loosened ruby version requirement #15

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