[Bug 520505] Spurious dependency on perl(Test::More)

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=520505





--- Comment #10 from Chris Weyl <cweyl at alumni.drew.edu>  2009-09-05 16:36:45 EDT ---
(In reply to comment #8)
> As said, it's been discussed before.  

So, again, do you have any real examples of "actual harm" specific to including
the tests as documentation, or is this all handwaving and FUD?  If I remember
correctly, there weren't any real examples the last time this came up,
either...  And if I'm being accused of causing Fedora "actual harm", I'd at
least like to see the evidence against me.


Dependency bloat (from %_docdir contents) is a long standing rpm issue that no
one seems willing to tackle; by policy we don't allow deps in %_docdir so
Fedora rpm shouldn't even look in there.  And frankly, I don't think it's
unreasonable to say that I've done more recently to help eliminate %_docdir and
other spurious deps by writing up and proposing the filtering system now in
place than any other effort I've recently seen.  (Corrections welcome.)  If rpm
conformed to Fedora policy, %_docdir deps wouldn't ever be an issue with any
package.

Catalyst test suites often contain mini test-apps that help demonstrate how
something actually works.  MooseX::AttributeHelpers was for ages poorly
documented; the tests were the only real way to help figure out how they
worked.  MooseX::Workers sounded really quite cool didn't make any sense until
I read through the test cases.  If one does a basic google search[1] for
'site:search.cpan.org AND ("see the test suite" OR "see the tests")': 
MP3::M3U::Parser ("See the tests in the distribution for example codes"),
Parallel::Forker ("For more examples, see the tests"), MooseX::Types ("See the
tests directory for a start on this", w.r.t. a specific coding scenario),
WWW::Netflix::API ("Also see the "TEST SUITE" source code for more examples"),
etc, etc.

As to "undocumented api"...  We all know the conventions, we all get to make
our own decisions, and we all know we're shooting ourselves in the foot (or
head) if we use internal methods.  If this were a real argument, we should
probably not allow any users to see the source code at all.  Or have root. Or a
keyboard. :)

I think the ability to run the test suite post-install is pretty important, but
we're installing them in %_docdir.  ATM the intention is to have them as
documentation; if someone uses them beyond that that's their own doing.  And I
hardly think running a test suite "post-install" is a "bad practice"; modern
Perl apps often have a fairly extensive dependency tree...  It's nice to be
able to validate that updating perl-Sub-Name, say, isn't going to somehow break
Class::MOP and thereby your Catalyst app.  Unless we start breaking them out
into -tests subpackages, we don't need to consider this here, however, as they
stand quite nicely on their own as docs.

Soo...  maybe the "undocumented" / "bad API" theories held some weight back in
1999, but this is 2009.  Modern Perl test suites are an entirely different
animal.  I'm more than open to reconsidering the merits of this, but I haven't
seen any of the "actual harm" claimed to be specific to including the tests in
%_docdir.

[1]
http://www.google.com/#hl=en&q=site%3Asearch.cpan.org+AND+("see+the+test+suite"+OR+"see+the+tests")&aq=f&aqi=&oq=&fp=3aa7f458acaa2672

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.