Is there a way to force an update of the Gemfile.lock without installing the gems that have changed?
Run bundle lock --update.
I found an answer in a blog post by Chris Blunt: “Rails on Docker: Quickly Create or Update Your Gemfile.lock”:
Today, I discovered a way to save the hours wasted downloading gems: bundler’s lock command.
This gem of a command resolves your app’s dependencies and writes out the appropriate Gemfile.lock – without installing any of the gems themselves.
According to the changelog, this command was added in Bundler 1.10.0.pre, released about eight months after this question was asked.
Instead of
bundle install
do the following:
bundle lock
This will just update the Gemfile.lock, but not attempt to install the files locally.
If you want to prepare a Gemfile.lock for a remote or deployment platform you must add it using
bundle lock --add-platform ...
Latest docs at https://bundler.io/v1.16/man/bundle-lock.1.html
UPDATE: This is still supported by the current (2.4) version but has been deprecated in favour of the lock command.
Force your specific requirement using:
bundle inject rmagick "=1.7.1"
Related
After installing PentestBox for installing penetration testing tools on windows 10 It was working great but some of the tools was outdated like metasploit, so I tried updating all using PentestBox Update Manager, but after finishing the update msfconsole keeps giving me this error
Bundler could not find compatible versions for gem "sysrandom":
In Gemfile:
metasploit-framework x86-mingw32 was resolved to 5.0.0, which depends on sysrandom x86-mingw32
Could not find gem 'sysrandom', which is required by gem 'metasploit-framework', in any of the sources.
and i literally suck in ruby language on general so what should i do ?
The version of metasploit you linked to doesn't appear to have been updated in a few years. It doesn't list sysrandom as a dependency in the Gemfile.
There's a newer version which does have sysrandom as a dependency, here:
https://github.com/rapid7/metasploit-framework/blob/master/metasploit-framework.gemspec#L106
I'm not sure why pentestbox is using such an old version, but I'm assuming the "update" actually updates to the rapid7 version of metasploit (because it's looking for sysrandom which only exists there).
There are a few things you can try:
bundle install should install all the dependencies (without using the console tool built for pentestbox)
Deleting the Gemfile.lock and running bundle install. I don't usually recommend this but if there seems to be a version mismatch somewhere and sometimes this resolves dependencies errors. You should be able to re-check this file out again (assuming it's versioned locally)
If you can post the git commit hash of the metasploit version you've downloaded that might help provide additional suggestions for resolving.
Bundler has a feature where you can install gems in parallel using the --jobs option. For example:
bundle install --jobs 4
Does a similar feature exist for RubyGems?
I want to be able to run gem update in the same way.
The root problem is that it takes FOREVER to update my global system gems.
No, this feature does not currently exist. However, there’s an unmerged pull request on RubyGems regarding downloading gems in parallel that may be integrated by the time you read this: https://github.com/rubygems/rubygems/pull/649. However, this PR does not address the installation of gems in parallel like Bundler does. So, some of functionality might partially be coming soon.
That said, telling RubyGems to do fewer things during installation is a good way to speed up installation. There are three relevant CLI options worth looking at.
Don't install documentation:
gem update --no-document
Don't attempt to upgrade gems already meeting version requirement:
gem update --conservative
Don't upgrade any dependencies that already meet version requirements:
gem update --minimal-deps
I recommend simply installing gems without documentation. The intent behind running a global gem update is usually “just give me all the latest stuff” so limiting the gems you’re updating would be in conflict that goal. However, many people don’t look at the RDocs generated for their installed gems, and it saves a lot of installation time.
http://guides.rubygems.org/command-reference/#gem-update
I tried to modify an existing gem and forked the git repository.
I added some commits and pointed bundler to my GitHub repository.
bundler update does recognise the change and downloads my version of the gem.
Anyway when I try to launch the application which depends on that gem (testkitchen) my changes aren't available. And when I delete the official version of the gem my version is not found/used and the app fails.
The weird thing is that all the official gems are installed to /var/lib/gems and my version goes to ~/.bundler
gem environment also shows up the correct directories
- GEM PATHS:
- /var/lib/gems/2.2.0
- /home/ansible/.bundler/ruby/2.2.0
I'm not using rvm or similar. Am I doing something wrong?
As #matt pointed out I forgot to add bundle exec to my commands.
I tried searching for this several times, but if this question has been answered already I didn't find it.
So, let's say I've developed a plain old gem (not a Rails app). I already know how to use Bundler for development, so I have a Gemfile and everything in my repository. However, I want this gem to use Bundler for dependency resolution when I install it, not just when I work on it.
Is there a way to do so, or would I have to resort to running its commands from a git checkout with bundle exec?
Bundler resolves dependencies not only for development. Just run bundle install on production server after deployment and it will install all needed gems there too.
If you need to install gems from several repositories, add row in you Gemfile:
source 'http://you_repository.com
Can not update gems on production server.
I've tried bundle install --deployment and bundle install --without development test
But keep getting:
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
If this is a development machine, remove the Gemfile freeze
by running `bundle install --no-deployment
EDIT
I don't know if this is correct, but needed a quick fix. I ran bundle install --no-deployment then bundle update then ran bundle install --deployment again
The instructions are probably a bit confusing. It's saying that you've modified your Gemfile on your development machine and just pushed those changes rather than running bundle install BEFORE committing the changes.
By running bundle install you will update your Gemfile.lock file. This should be pushed to your server as it's more important than Gemfile. Consider the Gemfile the plans for the Gemfile.lock file.
Always remember to:
Run bundle install if you change your Gemfile, even just to make sure. If it's too slow, pass --local through which forces it to only use local gems to resolve its dependencies.
Commit both the Gemfile and Gemfile.lock file to your repository
Deploy both the Gemfile and Gemfile.lock to your production servers to ensure that they're running the exact same dependencies as your development environment.
Running bundle update by itself can be construed as dangerous that will update all the dependencies of your application. It's mainly dangerous if you don't have solid version numbers specified in the Gemfile. I wrote about it here.
FWIW I had this problem and fixed it by removing some conditional statements from my Gemfile (conditionals on OS) and rerunning bundle.
FYI: You can also get this error if you use source blocks like this:
source 'https://rails-assets.org' do
gem 'rails-assets-jquery'
end
You'll see an exclamation point in the Gemfile.lock for this gem:
rails-assets-jquery!
Just define the additional source normally, i.e.
source 'https://rails-assets.org'
gem 'rails-assets-jquery'
(BTW cf. here about using multiple gem sources.)
This can be caused by an old version of the bundler gem on the server you're deploying to (in this case production). Logging into the server and running a gem update bundler resolved the issue for me. The server I was deploying to was running version 1.7.4 and the current version was 1.9.
I had an issue with my production server still using an old version of a gem, even though the Gemfile.lock showed the correct, updated version. My production server was running on Unicorn - and shutting down / starting it back up again fixed the issue - instead of sending the HUP signal, which did jack all to fix the issue.
bundle install failed on my "development" machine because of the mysql-gem on osx...
I also needed a quick fix. So I cloned the repo to a new folder on the production machine, ran "bundle install" there and committed the Gemfile.lock to the repo.
I have had this problem (Ubuntu 12.10 & 12.04, one of which behind a proxy server).
My problem was that I had some git:// protocols in the Gemfile. Changing this to http:// helped me get it all working.