Simpler version matching

[seanlinsley]

Since Rubygems doesn't have a way to require optional runtime dependencies, when working on the Active Admin gem I've often been frustrated by the available methods to version-check a loaded gem.

It seems like the correct way is:

Gem::Requirement.create('> 3').satisfied_by? Gem.loaded_specs['rails'].version

Not the easiest thing to remember, which I assume is why I often see developers comparing against the split version constants Rails provides:

Rails::VERSION::MAJOR > 3 && Rails::VERSION::MINOR > 2

Or, for gems that only have a version string:

Draper::VERSION > '1.3.0'

Both approaches get more complex of you want to correctly deal with prerelease versions, or match a range of versions.

To make development easier I built an abstraction layer:

ActiveAdmin::Dependency.rails? '>= 3.2', '< 4.2'

ActiveAdmin::Dependency.rails >= 3.2

ActiveAdmin::Dependency.rails! '~> 4.1'
# raises an exception: You provided rails 3.2.18 but we need: ~> 4.1.

ActiveAdmin::Dependency.devise!
# when not provided, raises an exception: To use devise you need to specify it in your Gemfile.

ActiveAdmin::Dependency['jquery-ui-rails'] < 5

Would this general feature set be desirable for Rubygems itself?

[drbrain]

Why not use gem 'rails', '>= 3.2', '< 4.2' which will activate the given version or raise an exception if it cannot be loaded or an incompatible version is loaded.

[seanlinsley]

I wasn't aware it was considered acceptable for gems to load dependent gems at runtime that way.

Regardless, that doesn't handle:

• soft dependencies (only run some integration code if the gem is available)
• conditional behavior for different versions of a gem

[drbrain]

For gems listed as dependencies in your specification there is no need to gem as the matching version will be activated at runtime. For optional dependencies you do need to activate a version and gem is the API for this.

I don't understand what your objections have to do with version matching via gem.

If you only want to run some code if some gem is available you still need to activate it via gem.

Changing the API for version matching doesn't handle conditional behavior for different versions of a gem either. The conditional code you need will likely dwarf the few characters of savings provided by a different API.

This is handled fairly cleanly by a case statement after you've activated a gem, though:

case Gem.loaded_specs['rake'].version
when Gem::Requirement.new '~> 10.0' then
  # …
else
  # …
end

I wouldn't mind changing satisfied_by? to accept a Version or a Specification as it seems redundant to supply the version. I wouldn't mind fixing Specification#satisfies_requirement? to accept a Requirement, Requirement string or a Dependency (Gem.loaded_specs['rake'].satisfies_requirement? '~> 10.0').

I am not particularly fond of method_missing and Matcher APIs as they create extra garbage that needs to be cleaned up.

I am not particularly fond of encouraging multiple version support as, in general, it does not encourage developers of libraries to commit to stable APIs. I prefer to follow in Matz's footsteps and make things you aren't supposed to do difficult.

I recognize for projects that extend Rails that this is an unfair, but I fear that adding this to make it easier to interact with Rails will lead developers to think API churn is OK for their library that is orders of magnitude smaller.

[drbrain]

I will streamline satisfied_by? and satisfies_requirement? as described above.

[copiousfreetime]

Proposal is:

• update Gem::Requirement#satisfied_by? to accept a Gem::Version or Gem::Specification
• update Gem::Specification#satisfies_requirement? to accept a Requirement, Requirement string or a Dependency

[bronzdoc]

This issue hasbeen ide for too long and nobody else has requested this feature, i'm going to close it for now