Browse files

allow people to set a local .Gemfile so that things like ruby-debug a…

…re not required for regular development
  • Loading branch information...
1 parent d57d809 commit a437986f433a775c7c370ad3f0273938015699df @tenderlove tenderlove committed Nov 17, 2011
Showing with 3 additions and 5 deletions.
  1. +1 −0 .gitignore
  2. +2 −5 Gemfile
1 .gitignore
@@ -2,6 +2,7 @@
# Check out for how to set that up.
7 Gemfile
@@ -36,13 +36,11 @@ gem "memcache-client", ">= 1.8.5"
platforms :mri_18 do
gem "system_timer"
- gem "ruby-debug", ">= 0.10.3" unless ENV['TRAVIS']
gem "json"
-platforms :mri_19 do
- gem "ruby-debug19", :require => "ruby-debug" unless ENV['TRAVIS'] || RUBY_VERSION >= "2.0"
+# Add your own local bundler stuff
+instance_eval ".Gemfile" if File.exists? ".Gemfile"
platforms :mri do
group :test do
@@ -69,7 +67,6 @@ platforms :ruby do
platforms :jruby do
- gem "ruby-debug", ">= 0.10.3"
gem "json"
gem "activerecord-jdbcsqlite3-adapter", ">= 1.2.0"

6 comments on commit a437986

Ruby on Rails member

@wycats, @hone, thoughts on making .Gemfile a built-in convention?

Ruby on Rails member

Is that coherent with the problem bundler solves? if you include an arbitrary private .Gemfile your dependency tree is in the general case unrelated to the one of the project.

Ruby on Rails member

Well... yes. At a minimum, it only works with projects that don't check in their Gemfile.lock, because suddenly everyone has a different one. But everyone already had a different one on this project, because of (for example) conditionals in the Gemfile.

Ruby on Rails member

Seems bad to make this a general practice. It (may) make sense for Rails to not version Gemfile.lock, but I personally advocate that as a bad practice to the majority of projects.

Ruby on Rails member

Well, any project that is a gem is not supposed to version Gemfile.lock, according to Yehuda :P

Ruby on Rails member
Please sign in to comment.