Is it possible to run the bundle viz command excluding gems from a specific group (usually the production one)?
Running bundle viz --without production does not work, so the syntax appears somehow different from the one of bundle install.
This was recently added, but it hasn't been released yet. See https://github.com/bundler/bundler/pull/3050
You can try cloning the Bundler git repository and running it from master. The easiest way to do that is to set up a shell alias to run bundle from your clone, as described in https://github.com/bundler/bundler/blob/master/DEVELOPMENT.md#development-setup
Related
I have a staging server. And I've got some issue I'd like to investigate right there. But I forgot to add byebug to Gemfile. I can surely add it locally, run bundle, commit to repository, deploy. But isn't there an easier way?
When I try to change Gemfile remotely and run bundle I get:
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 /home/gccs/website-backend/releases/20161018143057/Gemfile freeze
by running `bundle install --no-deployment`.
You have added to the Gemfile:
* byebug
Gems are installed with capistrano, basically, like so:
bundle install --path /home/user/app/shared/bundle --without development test --deployment --quiet
Edit .bundle/config changing BUNDLE_FROZEN: '1' to '0' (or removing it) is enough in order to be allowed by Bundler to manage gems in a deployment environment. Then you can edit the Gemfile, run bundle, restart your application and the custom gems are ready to be used.
If you intend to use them outside of the application runtime (f.e. if you need pry in rails console) restarting the server is not needed.
The reason why you're unable to install additional gems is because the bundle is frozen. You can check it like so:
$ grep FROZEN .bundle/config
BUNDLE_FROZEN: '1'
If you remove the line (as suggested by mdesantis) or change "1" to "0", you'll be able to install whatever gems you like, as if it were developer machine. But generally it's best to restore the value, if no more needed. Not sure if bundler will do that automatically on next deploy.
I have a ruby program in my git repo, used by a team. It's executed directly out of the git repo. I don't want all the team members to have to deal with gems, so I want the production-level gems to be installed system-wide (on shared disk). Bundler will use the git-controlled Gemfile.lock to decide which gems to pick up.
For development, I often install gems using --user-install.
Problem: I might accidentally push changes that use gems which are only user-installed, which will break other team members when they pull and try to run.
How can I ensure that all non-development gems are installed system-wide?
Is there a bundle command I can run that will detect this and throw an error? Or can I somehow get my cucumber tests to run using only system gems?
There is no way to get Bundler to use System gems, though I think there should be: https://github.com/bundler/bundler/issues/1964
The most straightforward solution for you would be to package the gems into your Git repo: http://bundler.io/v1.12/bundle_package.html.
This is really how the bundler team recommend that it should be run in a case where you want a user to be able to run your app without having to install gems locally.
A second option would be for you to use the --path option to bundle install and point that to a shared location visible to all your users. This option is remembered, so check .bundle into your Git repo and then your users would use the same configuration and reference the same location when they run bundle. Since all of the gems would already be installed there by you, they would have no problems.
I was fiddling around with the --deployment option on my ruby app. After that I wanted to add another gem to my app. I added it to the gemspec, and ran bundle install but the new gem didn't get installed. I deleted the vendor cache, .bundle, Gemfile.lock and tried again, and got the error I expected:
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.
...
I had seen this before, so I proceeded to use --no-deployment flag. For some reason though, the same error popped up again. An hour later I'm still stuck in the same place. No matter what I do, I can't get bundle install to work and install the new gem.
Is this some sort of strange error? Or bundler by design?
Pff... Somehow a .bundle config folder sneaked into my home directory, which made all repos on my machine look like deployment repos to bundler. Deleting the .bundle folder resolved the issue.
You can list the current configurations by running
bundle config list
After that, if deployment is set to true, for instance, just do
bundle config set deployment false
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.