David Golden wrote:
CPAN is a core strength of Perl because it makes developer's lives
easier by not reinventing the wheel.
This is not necesarily the case.
Every language has ways of providing additional libraries that make
developers lives easier by not reinventing the wheel.
CPAN is a core strength of Perl for the same reason .deb packages are a
core strength of debian.
Not only do they fulfil the "not reinventing the wheel" role, but they
do so in a way that makes the procurement and installation of those
package dramatically easier than the alternatives.
And the ease of procurement of a piece of software is twice as important
to success than the quality of the piece of software.
The person installing something from CPAN has ONLY two reasonable outcomes.
1. The module or application, and all the dependencies, install correctly.
2. The installation process fails, and the end-user cannot use that
software.
Additionally, dealing with recursion-based issues is paramount.
One thing I keep repeating over and over is that for MOST cases, nobody
will ever use the modules they are installing, nobody understands what
they do, and nobody will ever read the documentation.
To use two examples here, Jifty developers install 50-100 packages that
are Jifty dependencies, and primary use exactly two. Jifty and Jifty::DBI.
That's a couple of percent at best.
For a more extreme example, JSAN users often come from the Ruby of
Python worlds. They aren't even Perl coders AT ALL.
They just want to install the JSAN client.
It is installation that has made CPAN successful, and the prioritisation
of installation over all other use cases is paramount.
> 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.
A market is a bad analogy for CPAN. Markets require choice, and
arbitrary layers of recursive dependencies makes for very little choice.
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.
Benefit: Improved quality of error reports for factors that do not
impact the functional operation of a module.
Cost: A percentage of your users can cannot use the module at all, give
up in disgust and avoid it in the future.
I see this balance as undermining the core functionality of CPAN for the
benefit of the author in catching minor nits. It escalates a minor
non-critical issue for an author into a critical issue for installers.
It's selfish and wrong.
Dealing with errors in non-functional areas is what we have CPAN Testers
for.
Functionality and installation always comes first.
Adam K
