Is there a prescribed way to "clean up" Ruby Gems which have native extensions that have failed to build. There are directories/files left in the gems directory, however gem list --local does not list them as being installed.
e.g. sqlite3-ruby, linecache, mongo
here is how you can remove a specific version of the gem:
gem uninstall (gem name here) --version (version number here)
to remove gems from a specific version and back use:
gem uninstall (gem name here) --version '<(version number here)'
this will remove all lesser versions.
no predefined way.
The good news is that with 1.9.2, it should not count these as gems anymore (I assume that you're on 1.9.1)?
Related
I believe I'm misunderstanding the way bundler works, but from the bundle install documentation it seems to indicate bundler will use locally installed system gems.
...
--system: Install to the system location ($BUNDLE_PATH or $GEM_HOME) even if the bundle was previously installed somewhere else for this application
...
The --system option is the default. Pass it to switch back after using the --path option as described below.
I'm not using rbenv/rvm or any other Ruby version manager. I'm using ChefDK as my primary development environment, which ships with Ruby and a bunch of preinstalled gems.
The full contents of the Gemfile, there is no Gemfile.lock yet.
source 'https://rubygems.org'
gem 'nokogiri', '1.6.3.1'
Local nokogiri installed
$ gem list --local | grep nokogiri
nokogiri (1.6.6.2, 1.6.3.1, 1.5.5)
System Gem location has nokogiri 1.6.3.1 installed
$ echo $GEM_HOME
/Users/arthur/.chefdk/gem/ruby/2.1.0
$ find /Users/arthur/.chefdk/gem/ruby/2.1.0 | grep nokogiri | grep 1.6.3.1
/Users/arthur/.chefdk/gem/ruby/2.1.0/cache/nokogiri-1.6.3.1.gem
/Users/arthur/.chefdk/gem/ruby/2.1.0/extensions/x86_64-darwin-12/2.1.0/nokogiri-1.6.3.1
/Users/arthur/.chefdk/gem/ruby/2.1.0/extensions/x86_64-darwin-12/2.1.0/nokogiri-1.6.3.1/mkmf.log
/Users/arthur/.chefdk/gem/ruby/2.1.0/gems/nokogiri-1.6.3.1
/Users/arthur/.chefdk/gem/ruby/2.1.0/gems/nokogiri-1.6.3.1/.autotest
/Users/arthur/.chefdk/gem/ruby/2.1.0/gems/nokogiri-1.6.3.1/.editorconfig
...
However, when I run a bundle install, it tries to install and compile libxml2 for nokogiri.
$ bundle install
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Using mini_portile 0.6.0
Building nokogiri using packaged libraries.
Building libxml2-2.8.0 for nokogiri with the following patches applied:
- 0001-Fix-parser-local-buffers-size-problems.patch
- 0002-Fix-entities-local-buffers-size-problems.patch
- 0003-Fix-an-error-in-previous-commit.patch
- 0004-Fix-potential-out-of-bound-access.patch
- 0005-Detect-excessive-entities-expansion-upon-replacement.patch
- 0006-Do-not-fetch-external-parsed-entities.patch
- 0007-Enforce-XML_PARSER_EOF-state-handling-through-the-pa.patch
- 0008-Improve-handling-of-xmlStopParser.patch
- 0009-Fix-a-couple-of-return-without-value.patch
- 0010-Keep-non-significant-blanks-node-in-HTML-parser.patch
- 0011-Do-not-fetch-external-parameter-entities.patch
************************************************************************
IMPORTANT! Nokogiri builds and uses a packaged version of libxml2.
...
What am I missing? How can I force bundler to use the already installed nokogiri 1.6.3.1 (that ships with ChefDK)? I'm trying to avoid having nokogiri compile libxml2 because that fails consistently on many different developer/operations workstations and has caused no end of grief. Thanks.
Edit
Thanks to Tim Moore, using bundle env I noticed in the output that bundler had shared gems disabled.
$ bundle env
Bundler 1.7.12
Ruby 2.1.4 (2014-10-27 patchlevel 265) [x86_64-darwin12.0]
Rubygems 2.4.4
GEM_HOME /Users/arthur/.chefdk/gem/ruby/2.1.0
GEM_PATH /Users/arthur/.chefdk/gem/ruby/2.1.0:/opt/chefdk/embedded/lib/ruby/gems/2.1.0
Bundler settings
disable_shared_gems
Set for the current user (/Users/arthur/.bundle/config): "1"
Gemfile
source 'https://rubygems.org'
...
Looking at the ~/.bundle/config, sure enough the global config was set.
---
BUNDLE_DISABLE_SHARED_GEMS: '1'
Once removed, Bundler resolves nokogiri 1.6.3.1 correctly and doesn't try reinstalling it. This setting should not be there by default, by default bundler installs with --system. I must have set this setting many months back and forgot I did.
Try running bundle env to verify that the install location is what you expect.
If not, check whether there is a .bundle/config or ~/.bundle/config file overriding the install path. The output of bundle env will tell you what configuration it is using and how it was determined (i.e., which file it was in or whether it was picked up from an environment variable).
Try removing all contents of gemfile.lock file. Save the file. Run bundle install again.
There are a couple of methods. In gemfile you can specify the path which will force bundle to use from there.
gem "my_gem", :path => "path to gem"
As i see the issue is with the default paths here. Try doing this.
ChefDK doesn't install gems globally, it installs them under /opt/chefdk so they won't interfere with "your" global gems. I suggest you leave ChefDK gems isolated as they should be.
You need to use the proper bundler and gem. If you're using ChefDK, then it includes its own bundler and gem executables. They should be inside the /opt/chefdk directory, I believe under /opt/chefdk/embedded (I don't use chefdk, so I can be 100% sure of that).
To work 100% inside that ruby install, you need to ensure that the chefdk binaries are in your path before the other ruby related binaries. You can verify that with which ruby which gem and which bundle.
All that said, you really SHOULDN'T be messing with the ruby install for chefdk. It's embedded for a reason, so that you don't accidentally mess it up. I'd suggest you stick with the system ruby for your own work, and let Chef handle its ruby.
From Bundler docs:
--path: Specify a different path than the system default ($BUNDLE_PATH or $GEM_HOME). Bundler will remember this value for future installs on
this machine
Your bundler may have cached a --path specified install command.
Try:
bundle install --system
This will tell bundler to use the system installed gems as opposed to downloading new gem copies to a folder specific gem collection.
I have installed installed RVM and tried to setup compass - had some errors, so I tried to do it by installing Ruby and then doing everything step by step. THe thing is RVM gems conflict with the ruby gems and whatever I do, even though I Removed .rvm and ran rvm implode and searched for the sas 3.3.0 folder and deleted it manually it still says that ..., because sass-3.2.19 conflicts with sass (~> 3.3.0) . WHen I do gem list it does not show 3.3.0 , when I try to run compass it's always the same, i'm tired of searching for solutions, but I don't want to reinstall my ubuntu and set everything all up again.
What else could I try to remove that hidden gem from the system? I tried everything I could find - no use at all! There has to be a way to exclude taht dependency to not include 3.3.0 at all!
Maybe installing rvm and creating new gemset would help?
These commands might help you out:
# remove all old versions of the gem
gem cleanup rjb
# choose which ones you want to remove
gem uninstall rjb
# remove version 1.1.9 only
gem uninstall rjb --version 1.1.9
# remove all versions less than 1.3.4
gem uninstall rjb --version '<1.3.4'
In our rails 3.2 Gemfile, there are some gems installed with option :git pointing to repo on github, such as:
gem 'ruote', :git => 'http://github.com/jmettraux/ruote.git'
After bundle install, we type gem list to list all the gems installed. However gem list does not list ruote as a gem installed. As a matter of fact, there is no ruote listed at all. We notice the same thing also happens to all rails engines which are installed with option :git pointing to repo on github. Why gem list does not list all gems installed? How can we assure that ruote is correctly installed?
According to the Bundler Documentation, gems from git sources will not show up in gem list because the gem command cannot process them, so Bundler has to do all of the work by itself. Bundler stores these gems in its own location instead. (Note that this location has nothing to do with the current project. It is in ~/.bundler/... by default.)
You can see that it is installed if bundle install completes with no errors. You can also use bundle show to see the list of gems that Bundler has set up for you.
gem list is not the right way to show gems installed for the app, as it will show system wide gems.
To check what gems are for this app and their versions, check Gemfile.lock. You'll have the most precise info there.
gem list is showing you all the gems installed on your machine.
When you have a gem with a different location than Ruby's gems, Bundler will store these locally for the project rather than system wide.
I have the Rails gem and the data_mapper gem installed on my local machine (macbook). When I am in my terminal, I can type which rails and it give me a directory like /Users/andyhuynh/.rvm/gems/ruby-1.9.3-p392/bin/rails.
However, if I type which data_mapper, I get data_mapper not found. How am I able to figure out what gems I have installed on my local machine? Many thanks for any help!
How do I know if I have a gem on my local machine?
Type gem list.
You are searching for executable files with which. You can list all gems with gems list or bundle list if you are using bundler.
You can search for specific gem with gem list | grep gemname or bundle show gemname.
In case you are using RVM or any other Ruby version manager, you might have it install in other Ruby version.
rvm list
will let you know which version you have installed and which one you are using. Check on other versions with:
rvm use 'ruby_version'
and then
gem list gemname
I updates my gems, now I get this error:
Unable to activate capybara-mechanize-0.2.7, because capybara-1.1.1 conflicts with capybara (~> 0.4.0) (Gem::LoadError)
I've googled and searched SO, but I'm a bit of a n00b and not really sure what I need to do next.
Thanks for your time,
Mike
You can try to delete conflicting gem by invoking gem uninstall capybara. You will be the prompted which version to delete.
To remove all old gems in one swipe just use gem cleanup.
After cleaning old version which, hopefully, you don't need you should be ok. Otherwise, consider using bundler (http://gembundler.com/) to manage gems in your projects and RVM, where you can have completely separate gemsets.
My general workflow is as follows:
In Rails/Sinatra etc applications I put vendor/cache in my .gitignore and run bundle pack which installs gems into that directory. That way I can keep installed gems local per application.
In my daily workflow I use RVM to switch ruby versions and install gems into gemsets which I can port across RVM rubies. http://beginrescuened.com. A popular and more lightweight alternative to RVM is https://github.com/sstephenson/rbenv.
So bundler manages my gem dependencies in a sane manner and RVM lets me manage gems at a granular level. I went through the dependency hell of plain old rubygems a while back, never again.
You've either got two versions of Capybara installed (both 1.1.1 and some other version). You can go a gem list --local (or if you're using Bundler do a bundle show) and uninstall one of them.
Or possibly you've specified that you want versions ~> 0.4.0, and the version number 1.1.1 is out of that range. That is, the specified version range ~> 0.4.0 will only work with 0.4.0 .. 0.4.x, and not 0.5.x or higher.