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.
Related
I just wanted to convert from ImageMagick v7 to ImageMagick v6.
while doing that, this error was happened.
bundle install doesn't work correctly.
It seems like json version is something wrong.
How do I fix this error?
Environment below
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin17]
Rails -v (couldn't find gem) (becuase bundle install can't work)
json list / json (default: 1.8.3)
multi_json (1.13.1, 1.11.2, 1.11.0)
Bundler version 1.16.4
Mac Mojave 10.14
when I do bundle install on terminal, then I got this error
Fetching gem metadata from https://rubygems.org/........
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies.......
Using rake 12.3.2
Using concurrent-ruby 1.1.4
Using i18n 0.9.5
Fetching json 1.8.6
Installing json 1.8.6 with native extensions
Errno::EPERM: Operation not permitted # chmod_internal -
/Users/***/projects/***/vendor/bundle/ruby/2.3.0/gems/json-1.8.6/tests/test_json.rb
An error occurred while installing json (1.8.6), and Bundler cannot continue.
Make sure that `gem install json -v '1.8.6' --source
'https://rubygems.org/'` succeeds before bundling.
In Gemfile:
rails was resolved to 4.2.6, which depends on
actionmailer was resolved to 4.2.6, which depends on
actionpack was resolved to 4.2.6, which depends on
actionview was resolved to 4.2.6, which depends on
rails-dom-testing was resolved to 1.0.9, which depends on
rails-deprecated_sanitizer was resolved to 1.0.3, which depends on
activesupport was resolved to 4.2.6, which depends on
json
I tried to do like this because error statement says Make sure that
gem install json -v '1.8.6' --source 'https://rubygems.org/' succeeds before bundling
but result shows like this
ERROR: While executing gem ... (Errno::EPERM)
Operation not permitted # chmod_internal - /Users/***/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/json-1.8.6/tests/test_json.rb
I can't understand this error statement
Errno::EPERM: Operation not permitted # chmod_internal -
Also, I goggled a lot, then I update commandlinetool follow this
https://howchoo.com/g/m2u0mmuwzda/macos-mojave-fix-invalid-active-developer-path
then, I did this command again,
sudo gem install json -v '1.8.6' --source 'https://rubygems.org/'
then, it's completely succeded like this.
Building native extensions. This could take a while...
Successfully installed json-1.8.6
Parsing documentation for json-1.8.6
Installing ri documentation for json-1.8.6
Done installing documentation for json after 1 seconds
1 gem installed
But, if I do bundle install, still doesn't work: they show same error.
My recommendation is if possible to start fresh. Maybe your rbenv was not installed correctly, try reinstalling it, I suggest using brew install rbenv https://github.com/rbenv/rbenv#homebrew-on-macos
Make sure to add the eval "$(rbenv init -)" to your ~/.bash_profile then open a new terminal.
Navigate to the project directory and install the Ruby version you need: rbenv install 2.3.1
You can make sure you are using that version by issuing rbenv use 2.3.1 and ruby --version.
Now install bundler for that Ruby version, I suggest 1.17.3 for now (the latest before 2.0.1) gem install bundler -v '1.17.3'.
You should be ready to bundle install.
The most common scenario I see for a message Installing ... with native extensions to result in errors is usually due to the lack of binaries, header files and C related code to build that native extension, in your case the issue is due to permissions, hence why I am suggesting some fresh installation.
I second #Danilo Cabello's recommendation to start fresh if you can. I just have a few other trouble-shooting ideas:
The fact that your bundle is installing gems in /vendor/bundle means that at some point, you must have specified the path with bundle install --path vendor/bundle as #mogbee alludes to. That path flag will load files associated with your gems into vendor/bundle instead of your system gem location. You might have done that if you're trying to keep the project's gems separate from any other project, but if not, you will need to update your bundler's gem path.
To do this, first, check for any issues by running bundle doctor. If no issues are found, check your bundle configuration with bundle env. Make sure that your RubyGems Gem Home and Gem Path are routed through .rbenv, so they should match and look like /Users/***/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0. If they don't match, run the rbenv-doctor command below which should make sure your rbenv installation exported the path properly.
If the output of bundle env tells you that you're actually running an older version of bundler (older than 1.16.4), I would definitely update, and would recommend version 1.17.3 as #Danilo Cabello did.
Second, I would run this rbenv-doctor curl command to check the status of your rbenv install: curl -fsSL https://github.com/rbenv/rbenv-installer/raw/master/bin/rbenv-doctor | bash (https://github.com/rbenv/rbenv-installer#rbenv-doctor).
Third, depending on the output of ls -l within your project folder, you may also want to recursively change owner/group for your ~/.rbenv folder to make sure everything is owned by you and not root (https://superuser.com/questions/260925/how-can-i-make-chown-work-recursively/260939#260939)
I have limited privileges on a shared machine I'm using, so I can't install gems the way I'm used to. For example:
$ gem install request-log-analyzer
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions into the /usr/lib/ruby/gems/1.8 directory.
Is it possible to install a gem locally? (if it matters, I'm trying to install this gem.)
I saw a number of posts on Stack Overflow that talked about using Bundler or gemfiles but I'm not installing this gem for a Ruby on Rails project - I just want to use it in isolation.
I'm running Linux, not sure which flavor though.
You can try:
gem install --user-install gem_name
Add the --local flag to your install:
gem install --local request-log-analyzer
If that causes any problems, try downloading the gem manually and pointing gem directly to it using:
gem install --local path/to/gem/filename.gem
If you want to install it to your user home, as per rubygems:
When you use the --user-install option, RubyGems will install the gems
to a directory inside your home directory, something like
~/.gem/ruby/1.9.1. The commands provided by the gems you installed
will end up in ~/.gem/ruby/1.9.1/bin. For the programs installed there
to be available for you, you need to add ~/.gem/ruby/1.9.1/bin to your
PATH environment variable.
The command for this would just be
gem install --user-install request-log-analyzer
You could just use RVM: Ruby Version Manager. It is a complete version manager, along the lines of node version manager (nvm) and others, in that it allows you to have different versions of ruby and different collections of gems for each project. It does the job of keeping gems isolated from each other as well as from the system ruby, but at the expense of learning a complete version manager.
When run without root, it installs locally in ~/.rvm and doesn't affect other users.
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.
As we know, ruby 2.0 on Windows has some problems which cause us have to install platform=ruby version instead of platform=x86-mingw32 version gems.
I've added --platform=ruby in .gemrc. Now when I install gems with gem install / update, it will install ruby version. But this seems not affect bundler. When I try to use bundle install / update, it will still install x86-mingw32 version.
If x86-mingw32 version exist in my system (even a ruby version also exist), bundle exec will use it, then my application will fail. Many libs have such problem, e.g. do_sqlite3, http_parser.rb, bcrypt-ruby, etc.
Now i have to use gem uninstall to remove the x86-mingw32 version manually almost every time I executed bundle update.
Is there any system-wide way to override bundler's platform? .xxxrc file? config file? ENV variables? Or even modify the source codes of bundler?
P.S. I've tried to modify the PLATFORM field in Gemfile.lock but no use. Adding :platforms => 'ruby' in Gemfile is also unhelpful (actually any gem marked as :platforms => 'ruby' will not be installed on Windows)...
Thanks!
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.