Austin Ziegler wrote:
> On 1/11/07, Jeremy Henty <jeremy / chaos.org.uk> wrote:
> > On 2007-01-11, Nathaniel Talbott <ntalbott / gmail.com> wrote:
> > > I'd much rather not have to manually go through each gem, figure out
> > > what it needs so that I can run its tests, store that somehow (since
> > > it's not in the spec), install the dependencies since they aren't
> > > already, and all that to just automatically run tests for the gems.
> > Maybe a simple convention is all that's needed.  (Echoing myself in
> > another thread.)  If the full test set for "foo" is too cumbersome,
> > release it as "foo-test".  It should be easy to write a script that
> > installs "foo-test" for every installed gem "foo".
> >
> > (Actually I think that the test-driven philosophy should encourage
> > developers to think of the tests as just part of the product and
> > package them as such whenever it is reasonably possible.  But there
> > are bound to be occasions when this is not practical.)
>
> Given your last paragraph, why would idempotency dependencies be any
> different than dependencies necessary to run the tests? If I were to
> switch all of my unit tests to rspec, would it be appropriate to mark
> my gem as depending on rspec? After all, only the people who are going
> to run the tests will need it, just as only people who are going to
> interact with the gem on a meta-level will need hoe.

How about:

spec = Gem::Specification.new do |gem|
   gem.add_dependency("something", ">= 1.2.0")
   gem.add_optional("rspec", "Test suite only", ">= 0.5.0")
   ...
end

And, at the command prompt:

C:\gem install something

Install required dependency something? [Yn]
Install optional dependency rspec (Test suite only) [Yn]
...

And the API would simply be:

Gem#add_optional(gem, comment, *requirements)

Regards,

Dan