Bundler compatibility checks

[rarkins]

I needed to hardcode bundler compatibility checks after discovering an unforeseen issue with @sleekybadger's compatibility check.

In short: a dependency may specify a Ruby range (e.g. >= 2.3.0) and a repository may also specify a range (e.g. ~> 2.5.3). We need to determine how to decide which cases are compatible and which not.

• If the repository range is entirely "inside" the dependency range, then it is compatible
• If there is no overlap then it is incompatible
• If there is some overlap but also some non-overlap.. then what?

The secondary problem is then how to calculate these. I'm thinking maybe we pull every Ruby version, then filter based on both ranges, and then check that the repository values are all contained within the dependency values.

@sleekybadger are you able to check how Bundler decides this?

Cc @bjeanes

[rarkins]

Example of where they are both ranges:

The other possibility is that the satisfies function is extended to accept two ranges, but I suspect that's a hard problem to solve.

[bjeanes]

Hmm... I feel like this might be overthinking it.

Bundler doesn't resolve the Ruby version (it has no control over it). Therefore, there is no reason to be juggling two ranges by the time we are evaluating a specific dependency.

It seems to me that you could reduce the ruby version to a specific version pretty quickly. Start with the highest version for which you have a built docker image, and iterate downwards until you find the first version that matches the project requirement. From there, use that concrete version in all other places.

Maybe I am simplifying some necessary complexity away with these assumptions, but I think breaking the resolution into two passes will make this much simpler.

[rarkins]

Bundler is aware of the chosen Ruby version(s) if you enter it into your Gemfile. And for example if you run bundle lock with the wrong version of Ruby, it will error. So it makes sense that Bundler would compare that Ruby version to any stated Ruby compatibilities in the dependencies. What I don't know is exactly how it does that comparison.

When updating Gemfile.lock, we use a similar to approach to what you suggest - we retrieve the list of all Ruby versions we have built (into docker images), and then take the highest matching one.

[rarkins]

Also, the reason for using the the double ranges is like this:

• your project Gemfile says it's ok to use versions 4,5,6
• the dependency's latest version says it's compatible with 5,6

In theory someone on the project could use v4 and then the project won't run if you install the latest version of the dependency.

[bjeanes]

Yes, but Bundler doesn't elect the version, it just short-circuits if being run in an incompatible version.

I think complicating this logic with intersecting ranges just for the rare event that you might upgrade to a version that is incompatible with a different Ruby version (but one which still satisfies the range in Gemfile) doesn't make sense.

In that case, the required version of Ruby should be bumped OR you change the strategy to bundle within the minimum supported version of Ruby instead.

How is this different than when you specify {"engines": {"node": "11.x"}}? That too can match any version from 11.0-11.9999 but it is reasonable to trust that resolving dependencies with ANY 11.x is OK to satisfy the dependency resolution process.

The exceptional cases can be just that: exceptional.

[rarkins]

Keep in mind that I plan to have Renovate bumping the versions in Gemfile too. My goal is that no dependency upgrade we propose should "break the build" by being incompatible with the Ruby version. And if it is incompatible, and you want to see it anyway, then at least we flag it.

Maybe the answer for now is to skip compatibility filtering at the datasource and allow all versions through, then wait if a "real" use case happens to someone and we have a concrete example to work off. Hopefully they find this issue :)

[bjeanes]

Keep in mind that I plan to have Renovate bumping the versions in Gemfile too.

Yep, I expect that given this is how Renovate works with other package managers.

My goal is that no dependency upgrade we propose should "break the build" by being incompatible with the Ruby version. And if it is incompatible, and you want to see it anyway, then at least we flag it.

Yeah I understand this. The case I'm trying to make here is that deferring resolving the Ruby version to a concrete version makes the logic more complicated without really protecting from a common case here.

Gems rarely define required versions of Ruby and where they do, they are generally doing so because they depend on syntax, semantics, or stdlib of a specific version or higher. If Renovate chooses the newest version it has available which satisfies the Ruby required range and using that concrete version for all resolution, you will catch all these cases.

It's conceivable that you implicitly raise the actual required version from 2.5.1 to 2.5.3 by depending on a gem which raises the actual required version, of course. To mitigate that, Renovate could instead choose the lowest version supported by the ruby range and simply not propose changes which place a requirement beyond that (and instead open an issue or something). Alternatively, you could also bump the ruby range in the Gemfile and flag this as a warning in the PR.

Ultimately, all the developers in the project will be using a concrete version. Either, they will specify a specific version in Gemfile or they'll have a range in Gemfile but a specific version in .ruby-version. The latter case is generally done so that bundling succeeds in deployment environments that automatically use latest patch versions.

I think it is entirely acceptable to list as a caveat that if users of Renovate aren't specific about the Ruby version Renovate will (depending on what you choose), raise the implicit dependency on Ruby by upgrading gems or not suggest the latest versions due to being pessimistic about their version of Ruby.

I'm curious what bundle update does here. Unfortunately, gems that specify dependencies on patch levels of Ruby are pretty rare. This, again, is a reason not to spend undue time optimising for this edge case.

[rarkins]

@bjeanes btw, you should see a Machinist PR in your master issue now. It's not been raised yet because of scheduling but should hopefully generate lock file without error this time

[bjeanes]

@bjeanes btw, you should see a Machinist PR in your master issue now. It's not been raised yet because of scheduling but should hopefully generate lock file without error this time

Yep I see it! I'll respond with feedback/thoughts in #2983 (and I can move my comment to another issue if you prefer somewhere else)