-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Module::Signature dependency #1
Comments
What's wrong with it? What makes e.g. Module::Pluggable an acceptable dependency and Module::Signature not? |
First of all, Module::Signature depends on an external executable or an XS module, and doesn't always install cleanly under some environments (http://www.cpantesters.org/distro/M/Method-Signatures.html). So if we depend on it, Test::Kwalitee (one of the reasons (or only one reason) why Module::CPANTS::Analyse should be an independent module from other server-side components) may fail to install, either, which is bad. Secondly, signature test is something you should do after you make a tarball, that means, it's useless when module authors run "make test" or "prove -lr t/" before they ship. As Test::Kwalitee is generally for module authors and not for users who install their modules, it probably would ignore a signature test anyway (like extracts_nicely). I doubt there's any good reason for Test::Kwalitee users to install Module::Signature. Thirdly, it has (or had) long been considered a module to avoid at least by some people (and I consider so too; see http://cpanratings.perl.org/dist/Module-Signature), so CPAN::FirstTime turns off its signature check by default. I think some of the issues noted at the rating page have already been fixed, but I don't want to encourage people to install it (as I said before, it's ok for a server-side maintainer, though I'm afraid it might increase the load significantly). I'm not saying that adding dependencies is simply bad; adding Module::Signature as a dependency has more downsides than upsides. |
And the signature test should probably be extra metrics because of the second issue I wrote above (it's not something module authors can easily test by themselves before they ship). |
This is not a hard dependency, there's a fallback to an OpenPGP Perl module.
M::C::A depends on XS modules, too. Someone who has trouble installing M::S for this reason will fail totally with M::C::A. This is not a good argument.
CPAN testers reports for the current M::C::A trial release overwhelmingly indicate success. If bugs in M::S prevent people from using it, the answer is not that M::C::A should stick its head in the sand, but instead the bugs in M::S should be fixed.
Authors should run
I agree that users should not run author tests. I trivially added What's the compelling part of it?
I find no evidence for this claim. Rather, the
The line-ending bugs mentioned by Robert and Burak are fixed in 0.54 and 0.67 each. The feature requests about subkeys and WoT are not implemented yet. The module is usable despite the lack of these features.
Do you have measurement numbers? Is the load so debilitating that M::S performs a denial of service?
The purpose of |
Do we really want people to install Module::Signature as a dependency? Even if they only use Module::CPANTS::Analyse as a dependency of Test::Kwalitee?
It's ok for a server-side dependency, but I think it better not to include Module::Signature dependency in Build.PL, and test if Module::Signature is available in Module::CPANTS::Kwalitee::Signature (and if not, just skip).
Thoughts?
The text was updated successfully, but these errors were encountered: