是否可以验证 Gemfile.lock 中的所有宝石是否存在于 https://rubygems.org？

Question

Is it possible to verify if all gems in a Gemfile.lock file exist at https://rubygems.org ?

I recently updated my elastic beanstalk platform version, and it failed due to the following error:

Your bundle is locked to mimemagic (0.3.3), but that version could not be found in any of the sources listed in your Gemfile. If you haven't changed sources, that means the author of mimemagic (0.3.3) has removed it. You'll need to update your bundle to a version other than mimemagic (0.3.3) that hasn't been removed in order to install.

It was difficult to debug due to all the complexities of a managed deploy system.

The reason it failed is that the author of mimemagic has removed version 0.3.3, and so I needed to update the gem to 0.3.6. (see gem versions history here: https://rubygems.org/gems/mimemagic/versions )

So my question is: is there a command you can run, eg bundle check_sources that scans the gems and versions in your Gemfile.lock and hits https://rubygems.org to verify that they all exist and are still available?

It would be similar to what bundle check does, but instead of looking for the gems on your local machine, it would look for them at the remote source.

Answer 1

After suggesting a feature request with the developers of bundler here: https://github.com/rubygems/rubygems/issues/4487 , they suggested at least a viable work-around. Simply run this command:

bundle install --deployment --redownload

The --redownload (or --force ) switch will force the download of every gem, even if the required versions are already available locally.

The --deployment switch forces the usage of the exact versions specified in your Gemfile (and ignore patch upgrades like ~> 0.3.2 which would normally upgrade to eg 0.3.6 ). The use of --deployment is common practice during deployments.

This solution isn't ideal since it requires a full reinstall of all your bundle's gems. But it works!

Thanks to https://github.com/deivid-rodriguez for this suggestion.

Answer 2

i'm experienced the same exact issue today, im running my project on docker and the solution was to change the mimemagic version on the Gemfile.lock, i dont know if is an optimal solution but saved my day:)