On 1/10/07, Nathaniel Talbott <ntalbott / gmail.com> wrote:
> On 1/10/07, Christian Neukirchen <chneukirchen / gmail.com> wrote:
>
> > It is easy to write a rakefile that downgrades itself.  Possible gem
> > hackers will have hoe installed anyway, there is no need to declare
> > this dependency.
>
> Yes, but in order for the Rakefile to do *anything*, rake would have
> to be installed, which it wouldn't necessarily be unless Hoe is a
> dependency.
>
> FYI, I originally stripped the hoe dependency from cooloptions, and
> have since added it back after further consideration. I'd love to have
> development dependencies separated out from runtime dependencies, but
> until then, the hoe stays in.
>
> A thought: if code that's not used at runtime is such an issue,
> shouldn't we be stripping tests, Rakefiles and the like from our
> libraries before gem'ing them? I don't see the difference between
> those files and the hoe dependency.
>
> Just my $0.02,
>

My gems do not have the Rakefile included, nor do they depend on Hoe /
RubyForge gems even though I use them and think they are great.  Tests
I keep because they can be run from the gem, and it's a nice check if
something goes awry.

When we build and deploy our C++ applications here at work, we do not
distribute the Makefiles or any of our supporting scripts.  Same
analogy applies to the Rakefiles and supporting gems.

That being said, it really does not matter one way or the other what
you put in your gem.  Unless your gem is full of crap, and then people
won't download it.  Hoe and RubyForge are "not crap" (TM).  It's just
surprising to some people when they are required.

My rule of thumb is to remove as much as possible from the gem and
still have it work.

Blessings,
TwP