Permalink
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...
tenderlove committed Nov 17, 2011
1 parent d57d809 commit a437986f433a775c7c370ad3f0273938015699df
Showing with 3 additions and 5 deletions.
  1. +1 −0 .gitignore
  2. +2 −5 Gemfile
View
@@ -2,6 +2,7 @@
# Check out http://help.github.com/ignore-files/ for how to set that up.
debug.log
+.Gemfile
/.bundle
/.rbenv-version
/.rvmrc
View
@@ -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"
end
-platforms :mri_19 do
- gem "ruby-debug19", :require => "ruby-debug" unless ENV['TRAVIS'] || RUBY_VERSION >= "2.0"
-end
+# Add your own local bundler stuff
+instance_eval File.read ".Gemfile" if File.exists? ".Gemfile"
platforms :mri do
group :test do
@@ -69,7 +67,6 @@ platforms :ruby do
end
platforms :jruby do
- gem "ruby-debug", ">= 0.10.3"
gem "json"
gem "activerecord-jdbcsqlite3-adapter", ">= 1.2.0"

6 comments on commit a437986

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Nov 18, 2011

Member

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

Member

indirect replied Nov 18, 2011

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

@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Nov 18, 2011

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.

Member

fxn replied Nov 18, 2011

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.

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Nov 18, 2011

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.

Member

indirect replied Nov 18, 2011

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.

@josevalim

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Nov 18, 2011

Contributor

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.

Contributor

josevalim replied Nov 18, 2011

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.

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Nov 18, 2011

Member

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

Member

indirect replied Nov 18, 2011

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

@josevalim

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Nov 18, 2011

Contributor
Contributor

josevalim replied Nov 18, 2011

Please sign in to comment.