I have a very recurrent problem here. (it happens literally all the time). I have found ways to go around it but i really would appreciate a solution for this problem:
Here is how it goes:
At my development machine, i have in my gem file a line like this:
gem "sqlite3-ruby", :require => "sqlite3"
what happens is that, when i bundle install --no-deployment, it goes alright:
Using sqlite3 (1.3.5)
Using sqlite3-ruby (1.3.3)
Updating .gem files in vendor/cache
Your bundle is complete! It was installed into ./vendor/bundle
But then, in the deployment, running bundle install --deployment, i get:
Using sqlite3-ruby (1.3.3)
Updating .gem files in vendor/cache
Your bundle is complete! It was installed into ./vendor/bundle
... which causes require errors that makes the application crash.. Then, what i do is bundle install --no-deployment at the deployment machine. Then i run again bundle install --deployment and then, magically:
Using sqlite3 (1.3.5)
Using sqlite3-ruby (1.3.3)
Updating .gem files in vendor/cache
And then the application runs fine.
So, what i most basically want is that bundler recognizes the sqlite3 dependency on sqlite3 gem
But then, in the development, running bundle install --deployment, i get:
Okay, this is the first suspicious thing. Why would you run --deployment in development?
You generally don't want to do that. If you're switching all the time between "--deployment" and "--no-deployment" on the same machine, it's easy to get things confused, yes.
Running "bundle install --deployment" will save something in the .bundle/config file in your project, that tells bundler "from here on out, only install these certain gems". "--no-deployment" removes that again, in case you made a mistake or need to hack around. But in general, you shouldn't need to and don't want to always be switching back and forth. Run --deployment on your production/deployment machine, don't run it on your development machine. You don't ever need to run --no-deployment unless you made a mistake and didn't mean --deployment
At this point, I'd rm -rf .bundle (it's okay, it'll just remove all the things bundler 'remembers' about what you want to do, like --deployment), and start over with bundle install.
If there's some reason this doesn't work, then that's the question.
From the line Updating .gem files in vendor/cache, I suspect at some point you also ran bundle package, which is another thing that's "remembered" in the .bundle/config thing, and is also probably interacting with your other commands oddly and doing things you don't expect. Removing your .bundle/config will get rid of that remembered setting too. (you may also need to delete your ./vendor/cache directory contents)
Just run bundle install unless you have a reason you understand for needing package, and understand what it does. Or it'll confuse you.
Related
While running the bundle install, it stops installing when it reaches the installation of the byebug gem. Saying, the gem maybe corrupt. I have tried uninstalling the ruby application and also tried updating my ruby and also my rails version
If you are using Bundler 1.1 or later you can use bundle clean, or bundle clean --force just as you imagined you could. This is redundant if you're using bundle install --path (Bundler manages the location you specified with --path, so takes responsibility for removing outdated gems), but if you've used Bundler to install the gems as system gems then bundle clean --force will delete any system gems not required by your Gemfile. Blindingly obvious caveat: don't do this if you have other apps that rely on system gems that aren't in your Gemfile!
Source -Bundle Clean
When i try to do bundle install, my gem_path and gem_home point to /usr/local/rvm/gems/ which i don't have write access and it fails because of invalid permissions. because of this i've changed both paths to a local directory where i do have write access.
when doing so, i do a bundle install, i get :
bruno#test6:~$ bundle install
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/..
Bundler::GemspecError: Could not read gem at /afs/varda.io/user/b/br/bruno/test6/cache/rake-10.1.0.gem. It may be corrupted.
An error occurred while installing rake (10.1.0), and Bundler cannot continue.
Make sure that `gem install rake -v '10.1.0'` succeeds before bundling.
well, if i do a gem install, it works just fine.
but bundle would just not work; even if a try to delete the cache folder that it complains about.
i did try "bundle install --no-cache" and it fails in the same way. (bundle install --deployment works fine too) how do i get bundle install to work ?
i've spent quite a bit of time, if anyone would have any guidance , i would really appreciate it!
Fixed it by deleting cache file and re-running bundle install.
rm -rf <location_of_cache>. In your case:
rm -rf /afs/varda.io/user/b/br/bruno/test6/cache
okay, first of all, you could solve all this issues easily by using rvm (user installation), see http://rvm.io, if that is not an option, you could try using project-specific gem paths.
for example i have the following bundler config file (~/.bundle/config)
---
BUNDLE_PATH: .bundle
BUNDLE_DISABLE_SHARED_GEMS: "1"
which causes bundler to install all gems in a .bundle sub directory (inside your project folder, where you run bundle install). now, if you remember to use bundle exec for your bins (e.g. cap(istrano)), you're fine.
if you somehow f*cked up your bundler / cache, try deleting the .bundle folder (in your project folder)
rvm reinstall all worked for me.
Before you do that, I would try
gem update --system
gem pristine --all --no-extensions
please note that rvm reinstall all takes a lot of time to complete...
If it's feasible, I recommend installing your own copy of rvm in ~/.rvm so you aren't tied to the system one. Trying to have a hybrid system+user approach will likely lead to more headaches later on.
Or, if you're open to alternate solutions, rbenv is a leaner & cleaner ruby manager.
Try to tell to bundler which folder it must use, something like bundle install --path <myfolder> or bundle install --path gems.
Note that I didn't test this yet, but it seems promising, please post the result for us.
I used to have a new ruby installation for each new rails project, because it's impossible not to have conflicting gems with between two of them.
I have seen that 'bundle package' command could freeze a project specific set of gems in the 'vendr/cache' directory.
I though it wouldn't install them globally, just store them in that directory.
However, when i did it, 'bundle package' ended up installing (globally) the gems before storing them in 'vendor/cache' folder.
Did I do something wrong? Is it a bug?
From the Bundler docs:
The package command will copy the .gem files for your gems in the bundle into ./vendor/cache.
As far as I can tell, Bundler does not handle installing gems, it passes that off to the gem command. What Bundler does is to make sure that you have the right version of the gem activated. So even when you package the gems, when you later install them it'll take those gems and install them "globally".
So, to answer your question: No, you didn't do anything wrong and this is not a bug but the intended behaviour.
This seems to happen a lot. I run bundle update or bundle install and for one reason or another I often get something like this:
You have already activated kgio 2.8.0, but your Gemfile requires kgio
2.7.4. Using bundle exec may solve this
I then have to go and run: sudo gem uninstall kgio and select kgio 2.8.0 to uninstall it.
Why does bundler even update the gem if it knows my gemfile locks those gems to a specific version. I NEVER install gems outside of the gemfile and bundler so Im not circumventing its conventions. I do have another project on my machine, but I havent ran a bunle update on that project in a long time -- is there some mix up there? Has this happened to anyone else? Am I doing something wrong?
actually bundle update the gems specified (all gems, if none are specified), ignoring the previously installed gems specified in the Gemfile.lock.
whereas bundle install will fetch all remote sources, but use the dependencies specified in the Gemfile.lock instead of resolving dependencies.
and use
gem cleanup
This command will remove (uninstall) all the versions of a gem, except for the latest one.
bundle update, installs newer versions of your gems and states that in your Gemfile.lock. bundle install just makes sure you have the correct versions installed. I suppose you are running bundle install in projects with different locked versions for kgio.
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).