Why does “batch upgrade” install ancient gems?

Everything worked fine until, from blue, the package update decided to “update” some very old versions of some gems. Any ideas? I'm confused!

The gemfile does not indicate a version for gems. eg.

gem 'rails' 

I...

 bundle update 

A (!)...

 Using rails (0.9.5) 

If I specify the version. eg.

 gem 'rails', '~> 3.0' 

Then this is normal.

 Using rails (3.0.7) 

Source 'http://rubygems.org'

Gem version 1.8.3, rvm version 1.6.14

Only some gems are wrong. the mangoid is another. This is at 1.0.6. Thanks!

+6
source share
2 answers

The problem is resolved. It was a huge conflict. I cooked it to ...

Only with these two gems:

 gem 'rails' gem 'i18n' 

You get i18n 0.6.0 (the last), but the rails are at 3.0.5 (3.0.7 is the last last).

And then only with these three:

 gem 'rails' gem 'i18n' gem 'delayed_job' 

You are getting:

 Gems included by the bundle: * actionmailer (0.6.1) * actionpack (1.4.0) * activerecord (1.6.0) * activesupport (3.0.7) * bundler (1.0.13) * daemons (1.1.3) * delayed_job (2.1.4) * i18n (0.6.0) * rails (0.9.5) <-- Yikes! that brings back memories! * rake (0.9.0) 

I did not look deeper into how the harness binding functions work, but this caused it. Interesting! And, of course, there is no need to turn on the i18n gem anyway, so removing this fixes things (or specifying versions of gem).

+6
source

Try it.

Just upgrade your picker. Maybe any of the old stones contradicts the latter, this type of problem arises.

 'gem install bundler' 

and then 'bundler install'

If you find the error again, then delete the GEM.lock file, then run bundler install . This can solve the problem.

All the best!!!

0
source

Source: https://habr.com/ru/post/888859/


All Articles