manual vs automatic bundler deployment with capistrano

[John Merlino]

I assume this is the most up to date documentation for running bundler
install when deploying a rails application with capistrano:

http://gembundler.com/v1.3/deploying.html

In the documentation, it offers two methods for deploying capistrano
with bundler: manual vs automatic.

Which is preferred?

[Robert Walker]

John Merlino wrote in post #1108980:

I'd choose automatic. Basically just add the require line to your
deploy.rb file just like it says there in the docs.

--
Posted via http://www.ruby-forum.com/.

[mike]

I agree that the "automatic" option is preferrable.  This documentation is not great and a bit dated.  If you are using Rails 3 or Rails 4, you don't need the statement 'require bundler/capistrano' and it may throw an error if you do.  You should list the gem rvm-capistrano as a requirement for your gemfile (you only need it in development).  

The "manual" method they refer to really doesn't have to be manual, but it can be.  Just to be clear, bundle install --deployment is something you run ONLY on the deployment server, NEVER in development.  I personally don't like this option, but it installs preconfigured versions of your gems in vendor/bundle (within the application).  It's used where you are deploying applications to multiple, identical servers (not common).  

If you have a need to bundle your gems within the application and not use gems in the centrally installed local directory, bundle package, IMO, is a better option.  You would then run bundle install --local to install from the package.  I would only use this if necessary, such as for private gems that don't exist in a repository.  

[Robert Walker]

mike wrote in post #1109071:

> On Tuesday, May 14, 2013 2:06:20 PM UTC-4, John Merlino wrote:
>>
> I agree that the "automatic" option is preferrable. This documentation
> is
> not great and a bit dated. If you are using Rails 3 or Rails 4, you
> don't
> need the statement 'require bundler/capistrano' and it may throw an
> error

Thanks for the clarification Mike. I wasn't aware that document was
out-of-date until I saw your reply. Good to know.