I have a website using Jekyll with Github Pages. After previously messing about with versions and RVM on another computer, on this one I opted to stick with just one version of Ruby and per-project environments using bundler.
I have a pretty simple Gemfile:
[$]> cat Gemfile
source 'https://rubygems.org'
gem 'github-pages'
and bundler config:
[$]> cat .bundle/config
---
BUNDLE_PATH: env
BUNDLE_DISABLE_SHARED_GEMS: '1'
When I run any command (jekyll, gem, irb) through bundle exec, I get a dependency error:
[$]> bundle exec jekyll
Could not find RedCloth-4.2.9 in any of the sources
Run `bundle install` to install missing gems.
However, the bundle is already installed:
[$]> bundle install
Using RedCloth 4.2.9
Using i18n 0.6.11
Using json 1.8.1
[snip]
Using github-pages 29
Using bundler 1.7.7
Your bundle is complete!
It was installed into ./env
I'm at a bit of a loss as to how bundler can think the gems are installed when using one subcommand, but think they're missing when using another.
[$]> which ruby
/usr/local/bin/ruby
[$]> which bundler
/usr/local/bin/bundler
[$]> ruby --version
ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin14]
[$]> bundler --version
Bundler version 1.7.7
After deleting the env directory and reinstalling, I noticed it created subdirectories for two Ruby versions - 2.1.0 and 2.2.0. The latter was my current version of Ruby, but the directory was empty (all the gems were installed into the env/ruby/2.1.0/gems directory). This, combined with Oliver's answer about rbenv, got me thinking about mismatched versions.
I reinstalled bundler with a simple gem install bundler, reran bundle install, and all is good.
It seems in general the answer is to sort out issues with bundler installing for a different version of Ruby than you're actually using. It seems strange to me it would use one thing for bundle install and another for bundle exec, but *shrug* whatever.
I had exactly the same problem after installing rbenv as my Ruby manager. In the end I solved the problem with:
rbenv rehash
(additionally you may need to restart terminal, as per #joel-glovier's comment)
That fact it's complaining about Redcloth 4.2.9 is actually a red herring. Bundler probably can't find any of the gems but Redcloth is the first one it looks for and so it exits imediately with that error.
Basically I'd installed rbenv and ruby 2.2.2 and changed to that version with rbenv global 2.2.2 but I'd forgotten to run rbenv rehash. So I'm guessing when running bundle install it was looking at my previously used version of ruby (system ruby) to see what gems were installed but when running bundle exec jekyll serve it was looking at my new ruby version and not finding any of the gems.
I had to open ./.bundle/config and set
BUNDLE_DISABLE_SHARED_GEMS to true for bundle the gems to be properly locally stored.
I had defined BUNDLE_GEMFILE = /home/app/current/Gemfile in .bashrc file. That broke the bundle exec while deploying a new version to the server. Check with env that you don't have the BUNDLE_GEMFILE defined in your environment variables.
I added the BUNDLE_GEMFILE into the .bashrc file to ease with monit commands. Now I just define the variable in the beginning of the monit command.
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.
So, not too long ago, this command worked on my computer, however, I don't remember if I changed something, but now after removing all my Ruby installs, and just having ChefDK 0.4.0 installed and in my path with the .chefdk/gem, and C:\opscode\chefdk\bin;C:\opscode\chefdk\embedded\bin in my path, I get the following result.
C:\Users\Phillip\Desktop\password_vault
λ bundle exec ruby bin\password_vault
bundler: command not found: ruby
Install missing gem executables with `bundle install`
C:\Users\Phillip\Desktop\password_vault
λ bundle install
Resolving dependencies...
Using rake 10.4.2
Using bundler 1.8.5
Using rack 1.6.0
Using rack-protection 1.5.3
Using tilt 1.4.1
Using sinatra 1.4.5
Using password_vault 0.0.1 from source at .
Bundle complete! 3 Gemfile dependencies, 7 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
C:\Users\Phillip\Desktop\password_vault
λ bundle exec ruby bin\password_vault
bundler: command not found: ruby
Install missing gem executables with `bundle install`
C:\Users\Phillip\Desktop\password_vault
I'm not sure what all else I could be doing wrong.
You have Ruby installed, because bundler is using it.
Somehow your bundle path doesn't have Ruby, or has lost track of it.
To solve this, use bundle --path, such as:
bundle --path "C:\foo\goo\hoo\ruby\bin"
The path is wherever you put Ruby on your system, plus any other path items that you want be available to bundler, such as bin directories of other software.
Bundler will remember the path for future installs on this machine.
I'm not a rubyist and there might be something obvious I'm missing.
I've wrote an application in Ruby 1.8.7, I'm trying to package it in Vagrant (running Raring 13.04), but I've to run "bundle install" to install the requirements and even though gem1.8 does exist, running bundle install still install the gems for Ruby 1.9.3. And then my program fails at runtime...
Any idea about how to solve this?
UPDATE 1
The related Gemfile (thanks to the first answerers):
ruby '1.8.7'
# ...
gem 'trollop'
but for ruby1.8 myfile.rb an error is raised
no such file to load -- trollop (LoadError)
After investigation, the problem looks in bundle install:
Your Ruby version is 1.9.3, but your Gemfile specified 1.8.7
I don't get how to solve the problem.
UPDATE 2
After following the advices from #klaffenboeck things have changed. I'm using RVM and have Ruby 1.8.7 when entering in the project folder. Bundler seems to install things correctly, however the require seems to fail... Path problem?
See here for detail about Vagrant / RVM setup: https://rvm.io/integration/vagrant
UPDATE 3
Problem solved, I was missing a:
require 'rubygems'
before all gems (it worked locally but not in Vagrant).
Bundler will install gems (by default) for whichever Ruby is in your PATH.
Try /usr/bin/env ruby -v or which ruby to figure out which one that is; my guess is you're running bundler with Ruby 1.8.
Adding
ruby '1.8.7'
on top of your Gemfile will help diagnose.
Not aware of this problem in general, but try to put the ruby-version at the top of your gemfile:
#Gemfile
ruby '1.8.7'
# followed by your gems
Edit:
this is most likely because your Gemfile.lock states ruby 1.9.3 - run bundle update
Try running gem uninstall bundler, then gem1.8 install bundler.
Your bundle command seems to be running under Ruby 1.9.3. You can verify which ruby executable bundler is using with head -n 1 $(which bundle). You want it to be ruby1.8.
I'm working in kali-linux (a linux distro witch is the continuation of Back-Track, based in Ubuntu, just that now is based on Debian wheezy) for some penetration testing. Everything was working just fine, until I decided to update my systems tools. Now whenever I try to run a tool based on ruby, it trows me:
Could not find gem 'ruby-progressbar (>= 1.1.0) ruby' in the gems available on this machine.
Run `bundle install` to install missing gems.
I proceed to run bundle install but then it comes with Bundler::GemfileNotFound error.
Kali use by default ruby, for using gems. The software don't 'require' any other package but ruby seems not-fully-configured/installed for the problem at hand.
$ ruby --version
ruby 1.9.3p194 (2012-04-20 revision 35410) [i486-linux]
$ rvm
bash: rvm: command not found
$ rbenv
bash: rbenv: command not found
I faced the same problem when I was trying to bundle install without realizing that I was not in the project directory. Make sure you're in the current project directory.
to avoid this error you should be at the root of your application and create GemFile and specify all gems needed in there, and run bundle install
The problem was that for some weird motive Ruby didn't detected that bundler was installed, although the package manager says so.
$ apt-cache policy bundler
bundler:
Installed: 1.3.5-2
Candidate: 1.3.5-2
$ bundle --version
Bundler::GemfileNotFound
I simply run gem install bundler then bundler install as root in the tool root path and everything works as charm.
Do you use rvm or rbenv? If so, make sure you are using a particular ruby version.
For rvm, rvm list and look for an indication next to your ruby version. If the correct one is not listed, run rvm install x.y.z. If the correct one is not selected, run rvm use x.y.z
If you want to segregate your gems for a given project, create a gemset. Otherwise, you should be good to go.
Run gem install bundler. You should not have to do this as sudo. This will install bundler in either the Default rvm gemset, or the selected gemset.
Bundler should now be available and can be run using bundle. This is the same as bundle install.
Try this:
sudo ln -s /var/lib/gems/1.8/bin/bundle /bin/bundle
sudo ln -s /var/lib/gems/1.8/bin/bundler /bin/bundler
Worked for me in debian.
I'm developing a gem which should install an executable.
At the moment I have a file at bin/myexec which does the work. I've got the line gem.executables = 'myexec' in my gemspec, and when I build and install the gem I can do bundle exec myexec anywhere and run my code - sweet.
I'm using rbenv, so I expect some slight shenanigans with binaries, but when I install this gem I need to always bundle exec myexec and I can't just myexec. I've poured over other gems (like guard) to see if there's some quirk of the .gemspec which implies that a rbenv binstub should be created, but I can't see anything.
What am I doing wrong?
Thanks!
If you are using your gem in another project and you installed it using bundler you have to stick with bundle exec myexec. To use your gem system wide you should install it using the gem command and rbenv rehash your environment.
I hope this helps, otherwise it would be nice if you provided some more information how you are using bundler etc.