This is my very first question here :)
On a rails 3.2.6 (using rvm and ruby 1.8.7), my Gemfile contains two gems that cause problems when using the bundle install command.
Those gems are specified using:
gem 'libv8', "~> 3.11.8.3"
gem 'therubyracer', '~> 0.11.0beta6'
My problem is the following: when running bundle install command, bundler fetches binaries (precompiled) gems (libv8-3.11.8.3-x86_64-linux.gem and therubyracer-0.11.0beta6-x86_64-linux.gem) and not the plain source ones (libv8-3.11.8.3.gem and therubyracer-0.11.0beta6.gem).
The x86_64 version is incompatible with my server setup: included dynamic library uses an unknown symbol (rb_intern2, out of my old memory, I could be wrong) that makes that the precompiled gems cant be loaded by the application.
So that I must install gem from the source packages.
At the moment, I have to bundle install, then remove the precompiled gems from my ~/.rvm/gems/... and then gem install ~/tmp/libv8-3.11.8.3.gem and gem install ~/tmp/therubyracer-0.11.0beta6.gem, which is not very practical.
Is there any way to force Bundler to fetch the sources release and compile them ?
try:
bundle install --without x86_64-linux
x86_64-linux is a platform and bundler/rubygems uses it.
It should be equivalent of:
gem install libv8 --platform ruby
Details:
http://gembundler.com/man/gemfile.5.html
http://guides.rubygems.org/command-reference/#gem_install
Related
I want to get a Gem's version without running bundle install.
Which is to say I want figure out what version bundle is planning to install without actually installing the gem.
Say read it from the Gemfile.lock(and Gemfile) combined.
Is there a way I can resolve what version bundler plans to install?
I need this because I want to cache the expensive installs while running docker build.
Gems like rails(nokogiri) take a while to install and I would like to do gem install rails -v ... in a previous step before running bundle install.
For this purpose i need to get the rails version before hand
If you add a new gem to your gemfile, but don't do bundle install, it doesn't install yet. Instead, you can run bundle lock, which generates a new lock file. This includes the gem version of the new gem that would be installed.
By running bundle show new_gem, it shows it isn't actually installed.
To be sure maybe get a backup of the original Gemfile.lock before running the command though.
By default if no version is specified in the Gemfile, running bundle install will attempt to install the latest version of the gem which is compatible with the rest of the gems and ruby version in your project. This will create a Gemfile.lock file if one doesn't already exist. If a Gemfile.lock file is already committed to git repo, it should then install the versions specified in Gemfile.lock. The point of bundler is to handle dependencies to insure your stack works correctly.
To see the version of a gem bundler is currently using you can run
bundle show rails
You will probably want to specify the ruby version in the Gemfile for example
ruby '~> 2.5' #
You can specify exact version of a gem in the Gemfile like this which you should be able to rely on to be the version bundler will install so long as it's compatible with the rest of the stack. bundle install will throw errors if there are incompatible gem versions.
gem 'rails', '4.2.11' # this will always install only this version.
You may also use pessimistic operator (~>) to set for only minor updates
gem 'influxdb', '~> 0.6.1' # could go to 0.6.2 but never 0.7.0
You can also set minimum versions like this although it's probably not what you need for your question.
gem 'pg_query', '>= 0.9.0'
If you have a Gemfile.lock already in your repo you can see which version would be installed by running for example:
gem show rails
Which would show you the version and weather it or not it is currently installed.
For more info see bundle --help
I'm trying to run bundle on a Win machine for an existing app. One of the gems is using HiRedis as a dependency. Since it is impossible to install HiRedis on Win:
Is there a way to find out which gem is using HiRedis?
Is there a way to run bundle command with --without [hiredis]?
You can find the gem which uses the hiredis, from the Gemfile.lock. Search for hiredis, and check to see under which Gem is that hiredis appearing.
In my Rails app, I have installed the gem sdoc from Github by specifying gem 'sdoc', github: 'voloko/sdoc' in my Gemfile. All was well until I recently updated Bundler to v1.6.0.rc.
Now I get the following error message when Bundler tries to load the gem:
There was a LoadError while loading sdoc.gemspec:
cannot infer basepath from
/Users/manuel/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/bundler/gems/sdoc-1a0e80c2d629/sdoc.gemspec:2:in `require_relative'
Does it try to require a relative path? That's been removed in Ruby 1.9.
I've already fixed the issue and submitted a pull request, but I cannot get rid of the "broken" gem!
This is what I tried:
removing the gem from the Gemfile or setting it to a different version
removing Gemfile.lock
deleting the gem folder /Users/manuel/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/bundler/gems/sdoc-1a0e80c2d629
gem uninstall sdoc (It doesn't even appear in gem list)
Nothing helped, every time I do bundle install or bundle update afterwards, I get the same error.
Any hints?
First-off: Clarifying a few things
From the Bundler documentation:
Because Rubygems lacks the ability to handle gems from git, any gems installed from a git repository will not show up in gem list. They will, however, be available after running Bundler.setup
Also, after deleting the gem inside the . . . /bundler/gems/ directory, you also should run rbenv rehash. This should get rid of the gem for you.
Answer:
Go to the root directory of your project (where the Gemfile resides) and run bundle clean. You have to pass either --path or --force switches. This should remove gems installed via git (usually if you have those gems installed and listed by gem list).
If you have issues. Delete the directories manually as you already tried and run rbenv rehash.
If I were you I would downgrade Bundler (ie. uninstall the RC release and install the latest stable).
I just installed RVM, Ruby, Rails etc. on my virtual ubuntu 12.04 32bit running in a virtualbox. Now I encounter the problem that for my first rails project bundle install or bundle update takes very long time. Even when I create a new project with rails (which includes bundle install).
I use only the standard gems:
source 'https://rubygems.org'
gem 'rails', '3.2.12'
# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'
group :development do
gem 'sqlite3', '1.3.5'
end
# Gems used only for assets and not required
# in production environments by default.
group :assets do
gem 'sass-rails', '3.2.5'
gem 'coffee-rails', '3.2.2'
# See https://github.com/sstephenson/execjs#readme for more supported runtimes
# gem 'therubyracer', :platforms => :ruby
gem 'uglifier', '1.2.3'
end
gem 'jquery-rails', '2.0.2'
I tried bundle install without any gems but gem 'rails', '3.2.12'. After that I typed again bundle install with all gems in my gemfile. It took me 10 minutes to check for dependencies. The output of --verbose is a mix of HTTP success and HTTP redirection.
Rails version: Rails 3.2.12
Ruby version: ruby 1.9.3p392 (2013-02-22 revision 39386)
Rvm: rvm 1.18.18
bundle version: Bundler version 1.3.2
I already searched fot a solution, but nothing helped.
I want to warn: There is a security purpose for using https over http. Try at first the other answers mentioned in this thread.
Changing https to http in my Gemfile did the magic. Before I have to create the project with rails new APP --skip-bundle
Bundler just got an update of parallel processing of gems.
gem install bundler --pre
will solve the problem in the best possible way for now.
Source
You can also use multiple jobs, it may improve a little bit
bundle install --jobs 8
Here is a tutorial about it
Bundler v1.12.x was released in 2016 and caused some users to experience slow bundle install issues.
In this instance staying with v1.11.2 is the best option (it's fast) until a fix is released.
It's worth heading over to Rubygems.org to try different versions of the bundler gem.
Check existing bundler versions, uninstall existing version, install version 1.11.2 example:
gem list | grep bundler
gem uninstall bundler -v existing-version-number
gem install bundler -v 1.11.2
A developer friendly method is to override the gem server with a faster alternative.
In our case, we can configure http as a mirror to address slow https connections:
bundle config mirror.https://rubygems.org http://rubygems.org
This allows you to keep original Gemfile configuration while still using faster http connections to fetch gems.
If you wanted to switch back to https:
bundle config --delete mirror.https://rubygems.org
bundle config has a default --global option. You can specify --local to limit configurations to local application folder.
Configuration is saved into global ~/.bundle/config and local .bundle/config.
If you're still seeing this issue with Bundler 1.12.5, you may want to try updating the OpenSSL used by your Ruby.
For me this went like so:
pmorse$ bundle --version
Bundler version 1.12.5
pmorse$ ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'
OpenSSL 1.0.1j 15 Oct 2014
pmorse$ openssl version
OpenSSL 0.9.8zg 14 July 2015
pmorse$ brew info openssl
openssl: stable 1.0.2h (bottled) [keg-only]
[... more brew output ...]
pmorse$ rvm reinstall ruby-2.2.2 --with-openssl-dir=`brew --prefix openssl`
[... lots of rvm output ...]
pmorse$ ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'
OpenSSL 1.0.2h 3 May 2016
This should make bundle quicker again without requiring you to go from https to http.
I know this may be basic answer but try to install developer tools from the main Ruby site. I have had a similar problem and it did work. Sometimes simple solutions are the best!
Good luck!
I've created a gem, and for some reason this one keeps bugging me, and refuses to install properly through bundler.
Here's the Gemfile:
source 'https://rubygems.org'
gem 'rails', '3.2.9'
gem "switch_access-rails", "~> 1.1.6"
bundle install fails with:
Could not find gem 'switch_access-rails (~> 1.1.6) ruby' in the gems available on this machine.
This works:
gem install switch_access-rails -v 1.1.6
And the gem is here on rubygems: https://rubygems.org/gems/switch_access-rails/versions/1.1.6
I even tried bumping from version 1.1.5 to 1.1.6 just to see if that helped.
Installing version 1.1.4 in with bundle install works.
Any tips on where to start looking/debugging bundle install?
And after a whole day of googling I found this status update from Dec 12: http://twitter.com/rubygems_status/status/279019743166476288
bundle install --full-index
Seems to get the index directly from rubygems instead of from a cloudfront cache.
I had a look at the index, and there is quite a diffence in the two indexes, so if you just released a gem or use a newly released gem, you might have to add --full-index in order to get the proper index.
Do you have rubygems listed as a remote source?
Your Gemfile should have source :rubygems at the top of the file, and $ gem sources should return at a minimum:
*** CURRENT SOURCES ***
http://rubygems.org/
If it's not listed, you can add it with $ gem sources -a http://rubygems.org