"Synthetic" gem constraints

[camertron]

Describe the problem as clearly as you can

This isn't a bug or a problem per se. I'm hoping to have a discussion about a feature I've been thinking about, but I haven't yet convinced myself it's a good idea.

For a while now, bundler has shipped with a feature that lets you specify the version(s) of Ruby your project supports. I seem to recall reading somewhere that the Ruby version constraint is implemented as if it were another gem whose version must agree with all the other gems in the bundle. What if such a synthetic version constraint could generalized and exposed as a public API?

Specifically I'm thinking of being able to specify certain versions of 3rd-party APIs a library supports. For example, I'm working on a tool that makes it easier to deploy Rails apps into Kubernetes clusters, and it would be convenient to be able to specify the Kubernetes version along with the gem dependencies. That way, the bundle would fail to resolve if a particular gem didn't meet the minimum Kubernetes version requirements.

Something like this, maybe:

source 'https://rubygems.org'

ruby '3.1.0'
constraint(:kubernetes, '>= 1.19', '< 1.23')

gem 'foo'
# etc etc

I'm curious to hear what others think about this, and whether or not it's a terrible idea.

One could emulate the desired behavior by publishing an empty Kubernetes gem, one version for each released Kubernetes version. That feels much worse.

[simi]

👋 Hello. Thanks for sharing your idea. I have moved this to discussions since it is not (as stated in description issue).

From my point of view RubyGems/Bundler is there to install RubyGems based on their dependencies. I don't think anything non-related should be part of the resolution logic. You can indeed create "meta" gem. Also you can use gemspec metadata to store custom additional info, but it will not affect dependencies resolution.