I had unicorn 4.5.0 and after I did bundle update, I observe different versions of the same gem even though I wanted to use the latest version.
unicorn (4.6.1, 4.5.0)
How do I instruct the bundler to just keep the latest version.
As far as I can see you cannot instruct bundler to keep only the latest version when updating. You can delete all the old versions of all gems in one go:
bundle exec gem cleanup
(Reference)
You can instruct bundler to just use one version by putting that version in the gem file. Sometimes, I have had conflicts with rake, even though I did not explicitly have rake in my Gemfile, so I had to put the rake version that would be usable by all the other gems at the top of my Gemfile.
If your issue is that you used to use unicorn 4.5.0, and now it has installed unicorn 4.6.1 in you local gem source, you can tell gem to uninstall the version you no longer need.
gem uninstall unicorn --version 4.5.0
If you did a bundle --deployment and populated the vendor/bundle directory, and that is where you want to remove the gem from, then I usually just delete the gem directory, however, I think you can run bundle with --path, like the following:
bundle --deployment --path vendor/bundle
gem uninstall unicorn --version 4.5.0
When you run bundler, it remembers the settings. I painfully discovered this regarding the --without switch. The --path setting will tell gem to use the local vendor/bundle directory as your local gem source. Remember to set the path back by running bundle again.
Related
I'm using Bundler version 1.3.5 and Ruby 2.0.0-rc2.
When I use the command bundle install --deployment on my production server all my gems are copied to vendor/bundle, except for the one that has a :git source in the Gemfile.
I don't get any errors and the gem is listed and even downloaded when running the command, but it's not in the vendor/bundle folder.
All resources I've found on this are related to out-dated versions of Bundler which did not have this feature. Why is this happening on 1.3.5, though?
Your "git" gem is stored and loaded from the cache directory. I think it's an implementation detail.
I've found the following note in the documentation:
While installing gems, Bundler will check vendor/cache and then your
system's gems. If a gem isn't cached or installed, Bundler will try to
install it from the sources you have declared in your Gemfile.
So the gem will be downloaded from git into vendor/cache, then bundler is going to install it, but it's already in the vendor/cache. So that is probably the reason, why you can't find it in the vendor/bundle directory.
I'm going through Micharl Hartl's well known Rails tutorial, and this piece is confusing me. Every time a new app is set up, these commands are run:
$ bundle install --without production
$ bundle update
$ bundle install
I don't really get why install is being run twice. What is the effect of these three commands run in this sequence?
You should not have to run bundle install twice as bundle update will also install all of your gems (as well as updating them to their most current version). I have not read the tutorial you mentioned but perhaps the purpose of the second install is to install all of the gems, including those reserved for production.
Your second question, what is the effect of these three commands:
bundle install --without production
Inspect the gemfile, ignoring gems that are reserved for production
Resolve all dependencies
Install all gems and dependent gems
Save the exact version of each gem to Gemfile.lock
bundle update
Inspect the gemfile
Resolve all dependencies from scratch using the newest version of each gem and completely ignoring Gemfile.lock
Install all gems and dependent gems
Save the exact version of each gem to Gemfile.lock
bundle install
Because this is the first run of the production gems, inspect the gemfile and resolve dependencies of the production gems
Use Gemfile.lock for exact versions of all other gems to be installed
Install all gems and dependent gems
Save the exact version of each gem to Gemfile.lock
Hoped this helped, for more detailed info about the two commands check out this and this.
$ bundle install --without production prevents bundler from installing any of the production gems. It also gets saved in your local repository and you don't have to run it more than once. Any subsequent run of bundle install will include --without production.
bundle install installs only the missing gems from your Gemfile, while bundle update updates/installs every single gem to the latest version as specified in the GemFile..
It seems when I run bundle package then bundle install --local then I run unicorn_rails, unicorn is still accessing system gems. I keep getting :
You have already activated rack 1.5.2, but your Gemfile requires rack
1.2.8. Using bundle exec may solve this.
And it shouldn't because rack 1.2.8 is in the vendor/cache.
bundle exec wont work because it seems to be a resource hog and the whole point of bundle package is avoid this whole mess in the first place.
So how do I get unicorn to get bundle environment to only use the vendor/cache gems?
bundle install --local takes gems in vendor/local and installs them using whatever your default gem command does. By default, that is a system-wide install. If you're using RVM or something else, it'll be in your current RVM gemset.
If you're installing in production, and you want to limit the app to your gems from vendor/local, you want to do bundle install --deployment. This will install the gems into vendor/bundle and set Bundler up to use those gems (and only those gems, not the system ones). If the gems aren't in vendor/local, it will download them. It won't update your Gemfile.lock, and best practice is to keep all your gems in vendor/cache up to date to prevent it from even trying to download gems.
You don't need to use bundle exec unless you're running a binary from one of the gems. If you're running rails server and having this problem, the reason is that the rails command is running from the shell's $PATH. It's presumably a different version of Rails than the one you'd like to use.
If that's the case, your options are to track down the path to the version of rails you want and run it explicitly, to use bundle exec, or to run bundle install --binstubs --deployment and add that bin directory to your PATH. I haven't noticed any overhead from bundle exec, but if you're concerned about that and still want to scope everything to your bundle, then use --binstubs (this is how Heroku does it, by the way).
I want to be able to define in my Gemfile that on my development machine (Windows 7) a certain gem (pg) version (0.14.0-x86-mingw32) should be installed, but on my production server (Debian) it should install the regular version.
I have tried defining groups in the Gemfile, but this does not seem to be reflected in the Gemfile.lock and when I run bundle install on my development machine (Windows), it lists the windows version of the gem in the Gemfile.lock. Then when I try and deploy with Capistrano, it runs bundle with the --deployment argument (and --without groups-i-want-to-exclude), which uses Gemfile.lock and doesn't install the pg gem at all because the version listed is for Windows.
I don't want to have to manually edit Gemfile.lock on my production server, because this is generally a bad idea, and each time I redeploy from my repo it will change back to the windows-specific version. I also don't want to turn off the --deployment option (my current solution) because this is not how bundler was intended to be used in this situation.
If you don't want to change Gemfile.lock on production server then you can change it on local machine. Try hope this work, change manually in Gemfile.lock after bundle install, and deploy -
PLATFORMS
ruby
x86-mingw32
As of yesterday, I'm unable to update my bundle. It gets stuck at "Fetching source index for http://rubygems.org/". I know this usually takes a while, but I've waited for hours and tried several times over the last day. I have a 20 Mbit internet connection.
I'm using gem 1.8.5, Bundler version 1.0.15, rvm 0.1.46, ruby-1.9.2-p0 [ x86_64 ] and Rails 3.0.8 on a Macbook. Gemfile: https://gist.github.com/1028832
The reason I'm trying to run Bundle Update is because the bundle was set to rake 0.8.7 until recently (not sure why), but rake started demanding that I move up to 0.9.2. So I changed the Gemfile. Bundle Install tells me to:
bundle install
Fetching source index for http://rubygems.org/
You have requested:
rake >= 0.9.2
The bundle currently has rake locked at 0.8.7.
Try running `bundle update rake`
My .bundle/config contains:
---
BUNDLE_DISABLE_SHARED_GEMS: "1"
BUNDLE_WITHOUT: production
I'm not behind a proxy.
I even tried deleting Gemfile.lock, reinstalling the ruby version in rvm and deleting all gems:
rm Gemfile.lock
rvm uninstall 1.9.2
rvm install 1.9.2
for x in `gem list --no-versions`;do gem uninstall $x -aIx;done
gem install bundle
bundle install
Comment out all gems and set explicit versions for rails (e.g. 3.0.8) and rake (e.g. 0.9.2). Then just run rake, cucumber and the server to see which gems you really need and add them back one by one manually.
I had the same problem with jam at “Fetching source index for http://rubygems.org/”
In my case it was solved by using the rubygems modern index instead of the API endpoint:
bundle install --full-index
I checked the Gemfile.lock and added the specific version (e.g. ~> 1.3.0) to the gems that had none in the Gemfile. Found out to be faster, than uncommenting gem by gem.
By doing the accepted answer and uncommenting gem by gem, I found that the error was due to incompatible gem dependencies. Maybe the resolution algorithm was stuck in a loop.