[Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11

Hugh Sasse hgs at dmu.ac.uk
Thu Jul 14 11:30:06 EDT 2005

On Thu, 14 Jul 2005, chad at chadfowler.com wrote:

>> On Thu, 14 Jul 2005, Chad Fowler wrote:
>>> On 14-Jul-05, at 6:31 AM, Hugh Sasse wrote:
>> I remember discussion about that flag only being a workaround for
>> the rdoc bug[s].  Organic memory may not serve me well here
>> though...
> Yea, though it was a case where rubygems was generating rdoc for a "super
> gem" whose only job was to cause other gems to be installed (over
> simplifying), so it actually makes no sense for the gem in question to
> have rdoc docs.

OK, though I'm not sure that having them would be bad.  Maybe
something is needed to make the rdocs say words to the effect of "If
this rdoc stuff looks completely bonkers, then it is because of
#{one_reason_of_several}", rather than just producing empty docs or
docs with other wierdness.

>>> give the gem author the ability to control default behavior and the end
>>> user
>>> the ability to override it.  What do you think?
>> Then, IMHO, it should default to true regardless of gem authors'
>> decreasing, but it should take effort to not provide them.  Yes,
> Agreed, though it actually _does_ require effort on the part of the gem
> author to not allow rdoc to be generated.  If you don't put "has_rdoc", it
> will generate rdocs.  The only way to make it NOT generate rdocs is to
> explicitly set has_rdoc to false in your gem spec.
> Make sense?

Yes, but I think it should warn loudly about this, at least until
standard ruby can output awful smells on most platforms :-)

As for Lothar's observation about infinite loops, we could put a
Thread based timeout around it.  I'm just wondering how YAGNI that
is, though.  Will rails || rdoc be healed soon?  I'm not really on
the inside of those projects so don't know how squeaky that wheel
is. #{raise MixedMetaphorError}
> Chad

More information about the Rubygems-developers mailing list