I have a simple Gemfile for an iOS project using cocoapods:
# frozen_string_literal: true
source "https://rubygems.org"
gem 'cocoapods'
gem 'fastlane'
gem 'jazzy'
I've tried to update my bundle by a bundle update and jazzy went from version 0.8.2 to 0.0.14 so I rolled back my Gemfile.lock and did 3 invidual updates of my 3 gems and everything went fine, ie jazzy was still in version 0.8.2.
I redid a bundle update and, again, jazzy went from version 0.8.2 to 0.0.14.
What am I missing here? Why do I get a different set of versions with the same constraints?
A gist with more details about the content of the files: https://gist.github.com/dirtyhenry/135ec7ef73f873d5ac3236bc3da633ba
The issue is dependency hell.
Fastlane depends on xcpretty, which depends on rouge of major version 2 (~>2.0.7) and jazzy itself depends on different versions of rouge, major version 1 (~> 1.5) so, bundler tries to resolve highest version of jazzy to reuse existing rouge dependency (which is 0.0.14).
However, you can force bundler to use version 0.8.2 an more of jazzy, add to your Gemfile:
gem 'jazzy', '>=0.8.2'
instead of
gem 'jazzy'
And perform bundle update again.
See more details on versioning in bundler docs
Related
I faced some issues with bundle install.
When we run 'bundle install' , One of the dependency gem in Gemfile.lock is get auto upgraded.
As per theory, "bundle install" will look the Gemfile.lock for version and won't resolve the version and will install the same versions. It will resolve only when there is no Gemfile.lock or when we give "bundle update".
In our server, we having Gemfile.lock but "bundle install" is updated the particular gem mentioned gemfile.lock(it's a dependency gem , so we not specified in gemfile), It should not happen like this, because already one version present in lock file, even though that version is get auto updated, Due to this upgrade some major functionality is broken in the site.
For your references:
bundler version - 1.17.2
ruby version - 2.5.3
gem version - 2.7.6
rails version - 5.2.3
that dependency gem name is "nokogiri", This gem locked as 1.11.7, But it's updated to "1.12.1" when i give "bundle install"
Any idea to prevent this issue in future?
First of all it'll be great if you shared the Gemfile.lock error so as to know what i particular might be causing that upgrade. But from afar I think as you said this gem is a dependency gem and it is not stated in your gemfile. It could be that another gem also depends on this gem and per that requirement it triggers an upgrade even before your supposed gem line is run which may be leading to the error. Read the error thoroughly and you can identify the gem(s) causing this.
After your update I have read around on this.
Exactly so as stated earlier on, one of these gems could be the reason why your particular gem gets updated with every bundler install. Unfortunately there is no true turn around to solving this but bundler does give a way around.
You can use the --frozen option with bundler which freezes your gemfile.lock to the current versions for each gem and does not update any gem but only installs new gems that you have. Unfortunately this has been deprecated and can only be done be done from /.bundle/config. This can be done from the command line in the root of your project.
run
bundle config frozen true to freeze bundler from updating your gems in gemfile.lock
You may have to grant write permissions to your user to be able to edit the bundle configurations.
I found this article as well from bigbinary.com
I'm upgrading my Rails application to 5.0 (5.0.0.1 current latest), I've also upgraded my Ruby version to 2.3.0p0 and bundler version to 1.13.6,
Now when I run bundle update it throws error like
devise (= 4.2.0) was resolved to 4.2.0, which depends on
railties (< 5.1, >= 4.1.0)
and so, I'd like to know if there is any automated way to auto update my gem version in gem file since I have around 100 gems in the GemFile
I would go with
$ bundle update
Because if gems you have specified in your Gemfile hasn't specified version, it will update your gems with latest available, and gems which has specified version with '~>' last patched version, for example from 1.0.1 to 1.0.2.
Also note, that bundle install will only install gems or missing gems specified in your gemfile, where bundle update will ugrade all gems managed with bundler.
Final, but that is just my opinion, I would wait with upgrading to Rails 5, just because not all gems are actually tested and upgraded to work with Rails 5.
You can do following things
Delete the GemLock file and do bundle install
OR
Do bundle update
If Still its not fixed
Remove the devise version that you have mentioned in GemFile and so bundle install so that it will automatically pick up the new version
I'm trying to upgrade to Rails 4.2 from Rails 4.1.9 and when I attempt to run the console or the server i get the following error. Any thoughts? I thought the html-scanner gem was included with Action::View
gems/activesupport-4.2.0/lib/active_support/dependencies.rb:274:in `require': cannot load such file -- action_view/vendor/html-scanner (LoadError)
The OP's issue (and mine) was to do with an incompatibility in the prototype-rails gem. This can be fixed by using the "4.2" branch of prototype-rails directly from github. Modify your Gemfile entry as follows:
gem 'prototype-rails', github: 'rails/prototype-rails', branch: '4.2'
Note that the prototype-rails gem will not be supported from Rails 5 onwards, so now would be as good a time as any to remove this dependency.
I believe they removed html-scanner from rails in 4.2 when they switched to rails-html-sanitizer according to the upgrade guide but it seems you can use the rails-deprecated_sanitizer gem to your Gemfile to then re-include the html-scanner library
gem 'rails-deprecated_sanitizer'
Hope this helps!
I've also had this problem on a legacy project. It's a bundler 1.17.3 / ruby 2.4 / rails 4.2.11.3 and it was driving me up the wall.
The following nasty hack worked:
Gemfile:
gem 'rails-deprecated_sanitizer'
gem 'prototype-rails', git: 'https://github.com/rails/prototype-rails.git', branch: '4.2'
but that wasn't enough. I then had to get rails-deprecated_sanitizer to appear where the gems wanted it.
So in my project, I created lib/action_view/vendor/html-scanner.rb:
require 'rails-deprecated_sanitizer'
require 'rails/deprecated_sanitizer/railtie'
require 'rails/deprecated_sanitizer/html-scanner'
(I doubt all three are needed, mind)
This depends on lib being in your load paths of course.
That fixed the problem, and I was finally able to reset the db and launch the server.
I'm using the thumbs_up gem and on github there's a master branch (0.4.6) and an engine branch (0.3.2). When I require the gem in my Gemfile with
gem 'thumbs_up'
I see that version 0.4.6 was installed. I verify this is the right version running in my dev environment by doing bundle exec gem which thumbs_up and when I look at the VERSION file I see it's 0.4.6.
So when I look at the code I'm expecting to find an unvote_for method but it doesn't have one. Instead it has one called clear_votes. Now I'm confused because clear_votes is supposed to be in version 0.3.2 but as far as I can tell, I'm on version 0.4.6.
Any ideas what's going on here?
By default, the gem used is the latest available when running 'bundle install'. You can specify a version (or version constraints) in the Gemfile. To update the version of the gem used, you have to run bundle update <gemname>, and it will do so according to your gemfile.
About your problem : ensure that your server/console command is prefixed with bundle exec. You check also which versions of thumbs_up are installer on your system, and remove the version you don't need anymore.
You use Bundler so you can know which version of you gem is using in your Gemfile.lock. Bundler have and use only one version by gem.
I just updated the mime-types gem with gem update mime-types. gem list displayed mime-types (1.16) prior to updating. After the update gem list shows mime-types (1.17.2, 1.16). Why are two version displayed?
More info: I have other Rails projects on the same computer. I have not updated the mime-types gem in any other projects. Running gem list from another project's directory (where mime-types has not been updated) displays mime-types (1.16).
You have both versions installed. If you want to delete old versions (which will not always will be possible due to dependencies) use gem cleanup.
Which version of RubyGems do you have? gem -v
This is interesting: I have the newest version of RubyGems but my system behaves differently:
gem list => all the gems, all the versions. No matter from where I call it.
gem list --local => same as before but user-wide.
bundle list => all the gems in a project (one version per gem)
The same goes for bundle update and gem update.
bundle update replaces the old version by the new one (the dependencies are taken care by bundler), but gem update keeps both. So if you want to keep only the newest version, run gem cleanup.
bundle outdated might be useful: it displays the outdated gems in your project (based on rubygems.org)
This can happen because of gem dependencies.
For example if another gem depends on that gem, and the other gem does not have a version specified for it, and(/or) it gets updated and if its dependency on that gem's version changes... well you get the idea.
Sometimes I do a bundle and I see a ton of new versions getting downloaded. All due to changed... dependencies.