Bundler entries in .gitignore

[Subbu]

Hi there,

What are the bundler related files/directories to be ignored from the
git repo? In other words, what do I need to add to .gitignore? I am
running a Rails 3 app.

In the article below:
http://yehudakatz.com/2009/11/03/using-the-new-gem-bundler-today/

Yehuda says we need to ignore: vendor/gems/gems, vendor/gems/
specifications, vendor/gems/doc, and vendor/gems/environment.rb. But
that was for an older version of bundler. The new vendor/bundle has a
different structure like below:
`-- ruby
`-- 1.8
|-- bin
|-- bundler
|-- cache
|-- doc
|-- gems
`-- specifications


Its not practical to add all these into my project's repo. Per the
article above I need to add ruby/1.8/doc, ruby/1.8/gems and ruby/1.8/
specifications to .gitignore. Is that correct?

Can anybody help me with this?

Thanks
-subbu

[Rhett Sutphin]

Hi Subbu,

You don't need to commit anything under vendor/bundle for bundler 1.0. You should ignore the whole thing. In bundler 0.7 and 0.8, you needed to keep the vendor/gems/cache directory because that was how bundler locked to a particular set of gems. In bundler 0.9+, locking is handled through Gemfile.lock.

If you do want to cache the gems for your application in bundler 1.0, you should use `bundle package`, which will put the cache in vendor/cache.

Rhett

>
> Can anybody help me with this?
>
> Thanks
> -subbu
>

> --
> You received this message because you are subscribed to the Google Groups "ruby-bundler" group.
> To post to this group, send email to ruby-b...@googlegroups.com.
> To unsubscribe from this group, send email to ruby-bundler...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ruby-bundler?hl=en.
>

[Rhett Sutphin]

Hi Subbu,

On Sep 29, 2010, at 1:01 PM, Subbu wrote:

You don't need to commit anything under vendor/bundle for bundler 1.0. You should ignore the whole thing. In bundler 0.7 and 0.8, you needed to keep the vendor/gems/cache directory because that was how bundler locked to a particular set of gems. In bundler 0.9+, locking is handled through Gemfile.lock.

If you do want to cache the gems for your application in bundler 1.0, you should use `bundle package`, which will put the cache in vendor/cache.

Rhett

>

> Can anybody help me with this?
>
> Thanks
> -subbu
>

[Subbu]

Thanks for the quick respone Rhett. That simple enough. Now the
question is, how do we handle bundle package with deployment in
picture? Do we add vendor/*/*/*/cache to the repo or at least symlink
it from a shared directory in the deployment server?

-subbu

[Donovan Bray]

I use bundler defaults and ignore

.bundle
vendor/bundle

Then I do

bundle install
bundle package

Then commit:

Gemfile
Gemfile.lock
vendor/cache

And use

bundle install --deployment

On production; and leave it to the devs how they want to bundle their own environment.

bundle install --path vendor/bundle

Will approximate a deployment install and leave the files under your source root. So when you do a search-all it also searches your dependent gems; downside is lots of hits for common items and slows all searches.

bundle install --local

Installs the bundle outside of your source root, but not in the system.

bundle install --system

Installs all the gems to the system; requires sudo privs

My preference is using the vendor/bundle path on my development machine.

[Subbu]

Thanks everyone. Everything is working fine with the following
deploy.rb:
require 'bundler/capistrano'

set :application, "myproject"
set :deploy_to, "~/websites/myproject"
set :user, "deploy"
set :use_sudo, false

set :scm, :git
set :scm_verbose, true
set :repository, '/home/subbu/repos/myproject.git'
set :local_repository, '~/projects/myproject'
set :branch, "master"
#set :deploy_via, :copy
#set :git_enable_submodules, 1

set :domain, "00.00.00.00"
role :web, domain
role :app, domain
role :db, domain, :primary => true # This is where Rails migrations
will run

namespace :deploy do
desc "Copy config files"
after "deploy:update_code" do
run "cp #{shared_path}/config/database.yml #{release_path}/
config/"
run "cp #{shared_path}/config/production.rb #{release_path}/config/
environments/"
run "ln -s #{shared_path}/vendor #{release_path}/vendor"
run "cd #{release_path}; bundle install --deployment"
end

# Passenger stuff
task :start do ; end
task :stop do ; end
task :restart, :roles => :app, :except => { :no_release => true } do
run "#{try_sudo} touch
#{File.join(current_path,'tmp','restart.txt')}"
end
end

On Sep 30, 6:07 am, Donovan Bray <donno...@gmail.com> wrote:
> I use bundler defaults and ignore
>
> .bundle
> vendor/bundle
>
> Then I do
>
> bundle install
> bundle package
>
> Then commit:
>
> Gemfile
> Gemfile.lock
> vendor/cache
>
> And use
>
> bundle install --deployment
>
> On production; and leave it to the devs how they want to bundle their own environment.
>
> bundle install --path vendor/bundle
>
> Will approximate a deployment install and leave the files under your source root. So when you do a search-all it also searches your dependent gems; downside is lots of hits for common items and slows all searches.
>
> bundle install --local
>
> Installs the bundle outside of your source root, but not in the system.
>
> bundle install --system
>
> Installs all the gems to the system; requires sudo privs
>
> My preference is using the vendor/bundle path on my development machine.
>