Cannot find file nokogirl after upgrading to v2.0.1

[christiannelson]

When I invoke rake g rspec:install this error occurs (some cruft removed for brevity):

/gems/activesupport-3.2.9/lib/active_support/dependencies.rb:251:in `require': cannot load such file -- nokogiri (LoadError)
  from /gems/activesupport-3.2.9/lib/active_support/dependencies.rb:251:in `block in require'
  from /gems/activesupport-3.2.9/lib/active_support/dependencies.rb:236:in `load_dependency'
  from /gems/activesupport-3.2.9/lib/active_support/dependencies.rb:251:in `require'
  from /gems/capybara-2.0.1/lib/capybara.rb:2:in `<top (required)>'
  from /gems/bundler-1.2.2/lib/bundler/runtime.rb:68:in `require'
  from /gems/bundler-1.2.2/lib/bundler/runtime.rb:68:in `block (2 levels) in require'
  from /gems/bundler-1.2.2/lib/bundler/runtime.rb:66:in `each'
  from /gems/bundler-1.2.2/lib/bundler/runtime.rb:66:in `block in require'
  from /gems/bundler-1.2.2/lib/bundler/runtime.rb:55:in `each'
  from /gems/bundler-1.2.2/lib/bundler/runtime.rb:55:in `require'
  from /gems/bundler-1.2.2/lib/bundler.rb:128:in `require'
  from /raygun/tmp/delme/config/application.rb:13:in `<top (required)>'
  from /gems/railties-3.2.9/lib/rails/commands.rb:24:in `require'
  from /gems/railties-3.2.9/lib/rails/commands.rb:24:in `<top (required)>'
  from script/rails:6:in `require'
  from script/rails:6:in `<main>'

With version 2.0.0 there isn't a problem. Might be related to #880?

Found this while working on my rail app generator, raygun. Follow the instructions in the readme to reproduce.(yanked the broken gem)

[walkeriniraq]

Had the same problem here with our rails app (using Konacha). Looking at the Gemfile.lock, it looks like the dependencies aren't getting added correctly...?

Relevant portion of Gemfile.lock:

    builder (3.0.4)
    capybara (2.0.1)
    childprocess (0.3.6)
      ffi (~> 1.0, >= 1.0.6)
    client_side_validations (3.1.4)

UPDATE:
Did a second bundle update and it magically fixed itself.

I've noticed some wonky bundler activity lately. A quick look at the bundler issues didn't show anything, but there are 350+ issues there and I don't have the time to mess with it right now.

[christiannelson]

The second bundle install fixes the issue for me as well.

Really strange that v2.0.0 works fine and v2.0.1 doesn't though.

[jnicklas]

I just double checked everything that could be wrong. I downloaded the gem files for 2.0.0 and 2.0.1 and manually unpacked them and compared them, they look identical. I went through the entire diff between 2.0.0 and 2.0.1, nothing which impacts the gem build process at all. I'm fairly convinced that this doesn't have anything to do with the 2.0.1 gem.

[mkempe]

Can confirm the “bug” and the “fix”.

Everything looks fine 2.0.0...2.0.1, must be a bundler problem.

[kerrieyee]

I've been having the same problem. 2.0.1 keeps raising nokogiri errors even after I ran bundle install multiple times. I finally just switched to 2.0.0 and that seems to work fine.

[christiannelson]

FWIW, I did a manual bisect and d21d6dd is the culprit. Looks like it's not capybara, but possibly something in xpath.

I guess it could be a rubygems or bundler issue too.

[jnicklas]

@christiannelson are you sure? It seems very strange that a git submodule would affect the gem. It isn't even part of the gem package.

[christiannelson]

@jnicklas You're right... I botched my bisect.

v2.0.1 results in this issue consistently and older versions don't. I'm going through all of the changes between 2.0.0 and 2.0.1 now to see what commit really causes the issue to surface.

[christiannelson]

@jnicklas Interesting. Using ref: '537fd691a8d6045dcf44aff22c880c609fcb6ece' in my Gemfile works but '2.0.1' does not. That suggests that the gem is either bunk (which you already checked), rubygems isn't producing correct dependency data for bundler (not sure if this totally makes sense) or there's a legit bug in bundler.

Thanks for looking into it and sorry for the goose chase.

[jnicklas]

No worries, you don't seem to be the only one having this issue. It's very strange, I did everything exactly like I always do, and I've never had a problem. It sounds to me like maybe rubygems or bundler messed up somehow. Maybe the dependency API is not returning the correct result for the gem. Since I still can't replicate it myself, I don't really know how to proceed though.

[christiannelson]

I pushed on this a little harder out of curiosity. I tried reproducing the error outside of raygun, since raygun is a bit of an oddity and has a lot going on. To my surprise it happened with a straight up rails app. Here's my console output:

https://gist.github.com/4132139

Thinking maybe something is up with my machine's configuration, I spun up an ubuntu vm and followed the same steps. The error came up there as well.

My guess is rubygems is coming back with incomplete dependency information. I might try to confirm that later after our holiday festivities.

[fabn]

I'm also having this issue with capybara 2.0.1 with dependencies not added. Pointing my Gemfile to github fix the dependency issue.

[danigb]

• 1 Can confirm the “bug” and the “fix” (double "bundle update")

This is strange. In my case, the missing dependency was xpath.

[mattheworiordan]

I had a case of missing xpath, specific error Gem::LoadError: Could not find xpath (~> 1.0.0) amongst ...
Then I removed the gem and installed again, now I have the missing nokogiri issue :(

$ bundle exec irb
>> require 'capybara'
LoadError: cannot load such file -- nokogiri
from /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-2.0.1/lib/capybara.rb:2:in `require'
from /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-2.0.1/lib/capybara.rb:2:in `<top (required)>'
from (irb):1:in `require'
from (irb):1
from /Users/matt/.rvm/rubies/ruby-1.9.3-p286/bin/irb:16:in `<main>'

Here is my bundle list:

Gems included by the bundle:
  * bundler (1.2.1)
  * capybara (2.0.1)
  * capybara-screenshot (0.3 f5f2f58)
  * diff-lcs (1.1.3)
  * rake (0.9.2.2)
  * rspec (2.8.0)
  * rspec-core (2.8.0)
  * rspec-expectations (2.8.0)
  * rspec-mocks (2.8.0)
  * timecop (0.3.5)

The fix for me was to bundle update capybara twice.

[mattsmith]

I just had the same problem a brand new rails app, just ran bundle update capybara and that installed nokogiri.
Here is my gist of what I did:
https://gist.github.com/4141934

I'm assuming it has something to do with the way bundler loads the dependencies.

[colvint]

+1 double bundle update capybara solution.

[emkman]

running bundle update capybara once fixed it for me. Interesting to note, I already had nokogiri installed but the update installed other gems that seemingly should have been installed during the initial bundle install.

Using nokogiri (1.5.5) 
Installing ffi (1.2.0) with native extensions 
Installing childprocess (0.3.6) 
Installing websocket (1.0.4) 
Installing libwebsocket (0.1.6.1) 
Installing rubyzip (0.9.9) 
Installing selenium-webdriver (2.26.0) 
Installing xpath (1.0.0) 
Using capybara (2.0.1) 

Something is definitely messed up with dependencies.

[michrome]

If it helps, pretty sure this was happening to me when I posted this on Stack Overflow http://stackoverflow.com/questions/13502511/rake-no-such-file-to-load-xpath

[christiannelson]

And this too: guard/guard-jasmine#90 (comment)

[jnicklas]

Seems like this problem has been solved with Capybara 2.0.2. I still have no idea what caused it, but I'm sure it wasn't anything inside Capybara. Closing this down.