Michael Peters wrote:
Adam Kennedy wrote:
It might be an interesting idea to also add a "dependencies_exist"
metric, that makes sure that all the dependencies that are declared
actually exist in the CPAN. Dunno, could be of dubiously little value,
but I just managed to somehow upload something with bad deps that I had
installed on my local machine, but that weren't all on CPAN yet...
I'm not sure this is such a good idea. There are several examples of modules
that rely on other Perl modules that aren't on CPAN. For instance, svk relies on
SVN::Mirror which is a part of svn. SWISH::HiLiter needs SWISH::API which is a
part of swish-e. 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.
98%* of modules are going to pass this, 1% will fail and encourage more
people to upload more things, and 1% will fail due to genuine errors we
want to assist authors in catching.
On another subject that came up today one one of my modules
(specifically the new Test::Object dependency of PPI) it seems like it
could be a bad idea to have explicit dependencies on the latest version
of a dual-life module.
One of the linux distro guys pinged me about Test::Object needing the
very latest (CPAN-only) version of Test::Builder, because it means they
can't package it properly for the distros without upgrading the main
Perl package. Some packaging systems can't handle having the same file
in more than one distro it seems.
While this might seem like punishing people for depending on things that
work, it's another red box to alert you to a possible problem, and the
red box will dissapear on it's own when the next version of Perl comes out.
I think it's worth considering.
Adam K
* Not actual percentages
