From: Wes Sheldahl <wes.sheldahl@...>
Date: 2007-01-11T23:10:49+09:00
Subject: Re: Tattle - The Ruby Census

------=_Part_44177_4145097.1168524645689
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/10/07, Austin Ziegler <halostatue@gmail.com> wrote:
>
> On 1/10/07, Evan Weaver <eweaver.spamtrap@gmail.com> wrote:
> > Eric Hodel wrote:
> > > By "build" I mean work on, not compile.  ZenTest is a build-time
> > > dependency for some of my gems because I use its assertion library
> > > when I'm building (adding features to or fixing bugs in) that gem.
> > You do not mean what I mean when you say "build-time". I think it is
> > good for a gem to include everything necessary to modify and redeploy
> > it. I do not think that should extend as far as forcing the user to
> > install external packages that they would only need if they decided to
> > do so.
>
> Again, this is a Gem problem, not a tattle, hoe, or rubyforge problem.
> The correct solution is to increase the amount of metadata that gems
> keep and provide hoe with a way of indicating that it is an
> idempotency dependency, not a run-time dependency. hoe-generated gems
> are absolutely correct, IMO, in indicating that they depend on hoe for
> idempotency. Gems is not correct in not providing this.
>
> -austin
> --
> Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
>                * austin@halostatue.ca * http://www.halostatue.ca/feed/
>                * austin@zieglers.ca
>
>
The problem is that Gem dependencies currently *are* run-time dependencies,
and hoe is using them differently. It seems to me that hoe should respect
the current definition and uses of dependencies in Gem, rather than act like
a requested change has already been made. Like it or not, hoe has chosen to
make itself a run-time dependency, because that's the only kind there is
right now.

If and when Gems do differentiate between different sorts of dependencies,
then and only then would it be appropriate for hoe to add itself as a
(non-runtime) dependency.

And going back to an earlier question about whether hoe should be merged
into Gem itself, I would hope that this would not make it any more difficult
to create and install gems that are intended for an internal corporate gem
server rather than rubyforge.

Thanks,

-- 
Wes Sheldahl
wes.sheldahl@gmail.com

------=_Part_44177_4145097.1168524645689--