Skip to content

"Synthetic" gem constraints #5375

@camertron

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions