On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> We also have dependencies on Sub::Uplevel (a notorious source of build
> problems),
Excuse me? CPAN::Testers for Sub::Uplevel 0.14: PASS 165 FAIL 0
There was a time when Test::Exception had things in build_requires
that should have been in requires. Test::Exception also exposed bugs
in nesting uplevel() calls, but this only affected modules that used
Sub::Uplevel and tested code with Test::Exception as well. In those
cases, Sub::Uplevel wasn't just a build requirement anyway and test
failure were quite helpful in finding and fixing the upstream bug.
> So for this trivial example, we have about 40,000 potentially unneeded
> installs and possible failures.
>
> Of course, that's a rough and stupid calculation and those numbers have
> NO MEANING, but it shows how quickly this could balloon. Now try and
> calculate this for all CPAN modules. You can see why false negatives
> are a fact of life and anything which avoids this would be wonderful.
<sarcasm>And if usage of Perl doubled, we'd have 80,000 unneeded
installs! So clearly the answer is to reduce the number of people
using Perl to reduce the number of unneeded installs.</sarcasm>
So, yes, that's a rough and stupid calculation.
CPAN is a core strength of Perl because it makes developer's lives
easier by not reinventing the wheel. More usage of modules means more
installs and points of dependency failure. Modules which use lots of
dependencies that might fail to install will themselves fail to be
installed more often and may be passed over and the world goes on. So
let's not start a "dependencies are bad" bandwagon -- let the market
figure out what dependencies are worth the risk. (I.e. your chance of
install failure is increased by the install failure chance of all your
upstream dependencies)
In my view, testing modules that make modules faster to develop and or
lead to better diagnostic output when failures do happen can make
author's lives easier, which leads to more development, which is a
good thing. If that means some extra installs, well, OK. Balance the
benefits to you against the likelihood that some people won't put up
with the extra dependencies.
The issue at hand is really *release* testing (i.e. did I bump the
version, did I test my Pod, do I use good style, etc.) being mixed
with *functional* testing -- and the corresponding push for release
testing modules being included as requirements.
For that, I blame -- among other things -- Module::Starter for
including pod.t and pod-coverage.t and with a default setting to run
tests. Better would have been to skip tests unless
$ENV{AUTHOR_TESTING} or some similar flag was set.
Yes, there's good defensive code to make sure Test::Pod and
T::P::Coverage are installed, but that just encourages people just
putting them in their prereqs as it's easy to imply that they should
be run if at all possible.
(There's also a tricky problem with T::P::C being happy with any
version of P::C, too: http://perlmonks.org/index.pl?node_id=508109 )
If some author wants to bear the risk of forcing them as a dependency,
fine. But I do think that the community shouldn't be actively
encouraging that through Kwality, Module::Starter and so on.
Regards,
David
