Bundler unable to lock new gem version even after publication

[benlangfeld]

Describe the problem as clearly as you can

With a specific gem (rails) locked to version 7.0.8, I am unable to upgrade to 7.1.2 despite this being available on rubygems.org. Doing gem install rails --version 7.1.2 works.

Did you try upgrading rubygems & bundler?

Yes, latest versions.

Bundler: 2.5.4
Rubygems: 3.5.4

Post steps to reproduce the problem

https://gist.github.com/benlangfeld/0cc8fa8b0e441cbd6427cf1f1bc35832

Which command did you run?

bundler lock --patch --strict --update rails

Leaving off --patch works.

What were you expecting to happen?

The Gemfile.lock should be updated with the new version.

What actually happened?

> bundler lock --patch --strict --update rails:
Fetching gem metadata from https://rubygems.org/..........
Could not find gems matching 'rails (= 7.1.2)' valid for all resolution
platforms (aarch64-linux, x86_64-linux) in rubygems repository
https://rubygems.org/ or installed locally.

The source contains the following gems matching 'rails (= 7.1.2)':
  * rails-7.1.2

If not included with the output of your command, run bundle env and paste the output below

https://gist.github.com/benlangfeld/3c608ad0ba53c934194477491f9f6b9e

[deivid-rodriguez]

Yeah, bundle lock --update --patch is not really prepared to be run on a situation where the Gemfile has been edited with a requirement incompatible with the lockfile. I'll try to fix it!

[benlangfeld]

Yeah, bundle lock --update --patch is not really prepared to be run on a situation where the Gemfile has been edited with a requirement incompatible with the lockfile. I'll try to fix it!

Just in case anyone is curious, this is in use by Renovate which is how I got to this point and why I can't simply remove that parameter for my use case. From the docs I couldn't find any mention of it being an inappropriate combination of options for this case, though. Making it work would be awesome, but if that's not possible, maybe a more specific error would be useful.

[deivid-rodriguez]

So I looked into this and, while it seems easy enough to make this "work", i.e. in the example you gave, update the lockfile to playbook_ui-13.15.0 to bring it in sync with the Gemfile, I'm not sure that's what we want.

In the example you gave, the Gemfile was edited to require exactly playbook_ui-13.15.0, while the lockfile is locked at playbook_ui-13.14.0. Then bundle lock --update playbook_ui --patch --strict was run, which means "update the locked version to the next available patch level version". However, there's no next available patch level version in this situation, and implementing the above would actually update playbook_ui's minor version, which goes against bundle lock --update playbook_ui --patch --strict specification.

So I wonder if perhaps we should just aim at printing a better error.

What's your expectation here?

[deivid-rodriguez]

#7376 would be the "solution" I attempted initially, but as I explained, I don't think we should go with that approach.

[benlangfeld]

So I looked into this and, while it seems easy enough to make this "work", i.e. in the example you gave, update the lockfile to playbook_ui-13.15.0 to bring it in sync with the lockfile, I'm not sure that's what we want.

In the example you gave, the Gemfile was edited to require exactly playbook_ui-13.15.0, while the lockfile is locked at playbook_ui-13.14.0. The bundle lock --update playbook_ui --patch --strict was run, which means "update the locked version to the next available patch level version". However, there's no next available patch level version in this situation, and implementing the above would actually update playbook_ui's minor version, which goes against bundle lock --update playbook_ui --patch --strict specification.

So I wonder if perhaps we should just aim at printing a better error.

What's your expectation here?

Thank you @deivid-rodriguez . I need to cycle back and understand Renovate's implementation and how it picks the --patch option here to give a better description of the requirements. I'll try to figure that out tomorrow and get back to you. It may be that Rennovate needs to modify its invocation of bundler; if that's the case, I'd settle for a better error.

[benlangfeld]

Sorry for the delay in following up on this. Looks like it was raised in Renovate at renovatebot/renovate#25955. I think it's reasonable to follow the path of working around this in Renovate, and I think just a better error in Bundler would suffice.

[benlangfeld]

@deivid-rodriguez In order to handle this case in Renovate, which is a little different to the case described in renovatebot/renovate#25955, it would be helpful to understand what sort of error Bundler might emit in the future. Do you have any idea how that might be written?

[deivid-rodriguez]

I was thinking something along the lines of

playbook_ui is locked to 13.14.0, while Gemfile is requesting playbook_ui = 13.15.0. --patch --strict was specified, but there are no patch level upgrades satisfying the Gemfile requirement, so resolving versions failed.

[benlangfeld]

, so resolving versions failed.

If we could go with "version solving has failed" that would match the other case and thus the conditional already in Renovate.

[deivid-rodriguez]

Yes, that makes sense 👍.