You can clone with
No one assigned
I'm using bundler in a small project where I require nokogiri. However, the inclusion of nokogiri fails with a strange LoadError.
I added 'gem nokogiri' to my gemfile and installed it all good with 'bundle install'. However, when it comes to using nokogiri with
commands, nokogiri fails with a LoadError. The strange thing is that I can load nokogiri by itself without any issues:
[x@y master]$ irb
irb(main):001:0> require "nokogiri"
[x@y master]$ irb
irb(main):001:0> require "bundler/setup"
irb(main):002:0> require "nokogiri"
LoadError: cannot load such file -- nokogiri/nokogiri
from /usr/share/gems/gems/nokogiri-1.5.4/lib/nokogiri.rb:27:in `require'
from /usr/share/gems/gems/nokogiri-1.5.4/lib/nokogiri.rb:27:in `<top (required)>'
from (irb):2:in `require'
from /usr/bin/irb:12:in `<main>'
My naive assumption is that bundler is changing the environment so that nokogiri fails to require its binary. This doesn't mean that bundler is the cause of this issue. I'm posting this issue here as well to get insights and help on further analyzing and boiling down the cause. Right now, I don't know how I can find the cause and fix the issue.
I'm using bundler 1.1.4 with ruby 1.9.3 on linux x86 box. I'm not using rails, nor using rvm. I'm quite new to ruby and bundler, so bear with me for my potentially inaccurate statements.
I already described this issue in the bundler mailing list and have been directed here to file this issue alongside with a gist containing information about the command in question and the Gemfile contents. Gist: https://gist.github.com/2935728
Any help is highly appreciated.
Hmm. It definitely seems like you have a problem with your $LOAD_PATH (which is how the require function finds things that you are trying to require). You might be able to work around it by running bundle install --path vendor/bundle? Before you do that, though, try comparing the contents of $LOAD_PATH before and after requiring bundler/setup. I tried your Gemfile and lock on my machine, and it worked without any problems:
bundle install --path vendor/bundle
[andre ✘ ~/sw/gems/bundler-testcases]$ git clone git://gist.github.com/2935728.git i1987
Cloning into 'i1987'...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (5/5), done.
[andre ✘ ~/sw/gems/bundler-testcases]$ cd i1987
[andre ✘ ~/sw/gems/bundler-testcases/i1987](master)$ ls
Gemfile Gemfile.lock LoadError
[andre ✘ ~/sw/gems/bundler-testcases/i1987](master)$ bundle install --path vendor/bundle
Fetching gem metadata from http://rubygems.org/.......
Installing blankslate (126.96.36.199)
Installing colored (1.2)
Installing cri (2.3.0)
Installing ffi (1.0.11) with native extensions
Installing nokogiri (1.5.4) with native extensions
Installing loofah (1.2.1)
Installing nanoc (3.4.0)
Installing rubypython (0.5.3)
Installing pygments.rb (0.2.12)
Using bundler (1.2.0.pre)
Your bundle is complete! It was installed into ./vendor/bundle
[andre ✘ ~/sw/gems/bundler-testcases/i1987](master⚡)$ irb
1.9.3p194 :001 > require 'bundler/setup'
1.9.3p194 :002 > require 'nokogiri'
1.9.3p194 :003 > require 'pygments'
Thanks for you suggestions. I did not yet try to workaround the issue by installing within vendor/bundle but want to get down to the root cause. Following your advice, I analyzed the $LOAD_PATH before and after the require calls. You can find the contents of the $LOAD_PATH variable in 2 scenarios in this gist: https://gist.github.com/2940316
Being a novice ruby guy, the interesting thing for me is that rubygems apparently seems to redefine the require statement and applies an extended strategy. The default $LOAD_PATH doesn't contain any path for nokogiri at all, but a require "nokogiri" succeeds and afterwards the $LOAD_PATH is extended to the nokogiri paths as well.
When using require "bundler/setup", bundler extends the $LOAD_PATH to support all gems within the bundle. However, it seems as if this extension is not completely ok since it seems to break the lookup and load strategy of rubgems' own require.
While analysing both cases, I found out that the working require via rubygems has a different $LOAD_PATH extension for nokogiri than the one with bundler.
The "standard" require "nokogiri" adds
while the require "bundler/setup" extends the paths for nokogiri to
which essentially misses the exts of nokogiri. (I'm too novice to understand why there's an exts folder but it seems as if these are by convention some binary libs).
My question still remains: What is the cause of this misbehavior and how can I fix it? All I want is just to use bundler in my little project and be able to do
as it is being stated on the http://gembundler.com/ page.
Thanks indeed for your assistance so far. Any further help / suggestions are very welcome.
I identified the issue as being a problem of bundler, since bundler does not respect the exts directory of nokogiri to be included in the $LOAD_PATH.
In my particular example, the folder being ignored by bundler is:
When bundler is not used and only
is issued with rubygems, then the path in question is being included in $LOAD_PATH and all is fine.
Now that I located the issue, I'm willing to find a viable fix for it. If anybody can tell me how to fix it, please do. You may even point me to the responsible code within bundler (it seems to be somewhere in environment.rb so similar). I'm willing to provide a test and fix for that.
I very much welcome any help regarding this issue.
Thanks for your support.
To be honest, that is an extremely strange setup. I have never seen or heard of a ruby that puts exts in a completely different hierarchy than the rest of the gem files. That said, there must be some code in Rubygems that finds the directory containing the ext that Bundler is not copying correctly. So maybe you should check the Rubygems source for the code that finds the correct directory, and I can try to help figure out where it should go in Bundler. Thanks!
Thanks for your support. It seems as if this extremely strange setup is at least fairly good replicable on Fedora boxes. I'll follow your suggestion and contact the rubygems guys as well as try to find the code in question by myself. As soon as I have valuable news, I'll update this issue. Thank you!
Any news on this? Might this has to do with a specific nokogiri version?
Thing is that adding s.add_development_dependency 'nokogiri', '1.5.2' to my gemspec, meaning setting nokogiri version to 1.5.2 fixes that same issue I was having (I have 1.5.5 installed too).
s.add_development_dependency 'nokogiri', '1.5.2'
I had the same issue with nokogiri when I updated bundler. I fixed this problem by reinstalling nokogiri for new bundler version.
It's super janky, but I fixed this problem (on my windows 7, 32-bit machine) by, just before to the call to 'require "nokoqiri", I added this line:
$: << "c:/Ruby193/lib/ruby/gems/1.9.1/gems/nokogiri-1.6.0-x86-mingw32/lib"
where $: is the array of paths searched for required files.
I did a non-exhaustive search but failed to find an environment variable or constant that would yield the path to the ruby executable ("C:/Ruby193/") or, better yet, to its "gems/1.9.1" This is further lame because it hard codes the nokogiri version and platform, but it got me passed my current hurdle. I'm very open to better solutions...
Closing because I believe this is working on latest versions of bundler - I haven't seen any nokogiri issues recently. @cedricdlb's issue looks different if he has to add lib to the load path - please open a new ticket following https://github.com/bundler/bundler/blob/master/ISSUES.md if it's still an issue.