Adam Kennedy wrote:
Michael Peters wrote:
There are lots of perl modules tied to various projects that don't
>> exist independently on CPAN.
But frankly, if you are uploading modules to CPAN that can't possibly
ever be installed with the CPAN client because you have to go install
modules from somewhere else first, I'd consider that worth docking a
kwalitee point over.
Remember that one of perl's great strengths is as a glue language.
Gluey modules are just as valid as gluey scripts, and arguably more
useful. When you buy glue, you get a tube of glue. You are expected to
seperately acquire the bits to stick together with your shiny new glue.
That a tube of glue doesn't come with the bits for you to stick
together is not a bug in the glue production and packaging process.
Likewise, that XML::LibXML, GD, DBD::Oracle, Win32::*, and countless
others have dependencies outside CPAN is likewise not a problem with
their packaging. Provided that the dependencies *are* available (and
not even necessarily available for free) and that finding them is not
made hard, then the module is, in this respect, packaged correctly. And
I don't particularly care whether such external dependencies are written
in perl, C, or some crazy moon language like Haskell, as there is no
substantial difference other than external perl dependencies being
easier to install than FORTRAN or Java libraries.
As a concrete example of why you might have to put modules on the CPAN
but not all their perly dependencies, consider the Mediasurface content
manglement system. It's a commercial program, written in perl*. I
could release a useful module for it to the CPAN, but obviously I can't
put Mediasurface itself on the CPAN. If you're going to deduct points
from a Mediasurface support module then I *insist* that you deduct
points from Win32::* and all the others I mentioned for the same reason
- that their authors are regretfully unable to upload Windows to the CPAN.
* it used to be anyway. They've probably reimplemented it in Java by
now because it really wasn't slow enough to be taken seriously as
Enduhprise software back in 1999.
--
David Cantrell
