Here's a summary of the minicpan test: Total number of distributions as of testing: 35806
- Has explicit "dynamic_config: 1" in META: 8606 (24.04%) - runtime prereq fails: 1953 (5.45%) - build/test prereq fails: 1496 (4.18%) - Has explicit "dynamic_config: 0" in META: 14906 (41.63%) - runtime prereq fails: 3642 (10.17%) - build/test prereq fails: 4233 (11.82%) - No explicit dynamic_config in META: 12294 (34.34%) - runtime prereq fails: 2611 (7.29%) - build/test prereq fails: 1551 (4.33%) As the number of implicitly dynamic distributions is a bit too big just to be ignored, I'd change the analyzer to scan distributions regardless of the dynamic_config and add some diagnostic message to each distribution page that requires dynamic_config, to show if the distribution's prerequisites match uses or not (and probably if it's statically installable or not), and mark the kwalitee fails only for the statically installable distributions. Does this makes sense? 2016-06-07 1:37 GMT+09:00 Kenichi Ishigaki <kishig...@gmail.com>: > Thanks, David. Fixed in the master (*), though I haven't deployed it > yet. I'll test it with minicpan first to see how big the impact is. > > https://github.com/cpants/Module-CPANTS-Analyse/commit/c3dea59f184983505458b74369b76dce7793f069 > > > > 2016-06-07 1:20 GMT+09:00 Karen Etheridge <p...@froods.org>: >> Yes, BUT -- for the purposes of kwalitee checks it might be reasonable to >> make the prereq_matches_use test more harsh if the flag is omitted entirely. >> Otherwise, this kwalitee test will not get to scan many distributions at >> all. >> >> On Mon, Jun 6, 2016 at 9:16 AM, David Golden <x...@xdg.me> wrote: >>> >>> Hi, Kenichi. >>> >>> There's a subtle possible bug. A missing "dynamic_config" field must be >>> considered true. The field is required for META.json (version 2), but >>> META.yml (version 1.4) might omit it. >>> >>> David >>> >>> >>> On Mon, Jun 6, 2016 at 11:59 AM, Kenichi Ishigaki <kishig...@gmail.com> >>> wrote: >>>> >>>> Thanks for the input. Fixed CPANTS analyzer (*) and started >>>> regenerating database. >>>> >>>> * >>>> https://github.com/cpants/www-cpants/commit/2cfff74754f202915e506332529f8ec43226c2db >>>> >>>> Kenichi >>>> >>>> 2016-06-07 0:30 GMT+09:00 David Golden <x...@xdg.me>: >>>> > Which Kwalitee test? >>>> > >>>> > Generally, as author of OSPrereqs and curator of the CPAN::Meta::Spec, >>>> > my >>>> > opinion is that any tool that draws conclusions about prerequisites in >>>> > META.yml/json is doing it wrong unless the "dynamic_prereqs" field in >>>> > META >>>> > is *present* and *false*. (Note that OSPrereqs sets it true.) >>>> > >>>> > That said, many tools (such as cpandeps) give pretty good results doing >>>> > it >>>> > wrong. But a Kwalitee test about prereqs in META should not flag a >>>> > distribution that has dynamic dependencies. I would complain to the >>>> > Kwalitee test author or else just ignore it. >>>> > >>>> > David >>>> > >>>> > >>>> > On Mon, Jun 6, 2016 at 11:15 AM, Alceu R. de Freitas Jr. >>>> > <cpan-testers-discuss@perl.org> wrote: >>>> >> >>>> >> Hello to all, >>>> >> >>>> >> I have a distribution on CPAN (Siebel::Srvrmgr) that uses Dist::Zilla. >>>> >> Some modules requirements are dependent of the OS where the >>>> >> distribution is >>>> >> installed. I'm controlling that with the plug-in OSPrereqs. >>>> >> >>>> >> All seems to be working fine except it is generating an issue with >>>> >> kwalitee test. A test from it is expecting to have all the prereqs >>>> >> declared >>>> >> in the META.yml file, but OSPrereqs is not generating them there, >>>> >> although >>>> >> the are (conditionally) considered in the Makefile.PL. >>>> >> >>>> >> I wonder if this is a bug of OSPrereqs Dist::Zilla plug-in, a problem >>>> >> in >>>> >> the standard or the kwalitee test itself. >>>> >> >>>> >> If there is any documentation that you can point me to I would >>>> >> appreciate. >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Alceu >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > David Golden <x...@xdg.me> Twitter/IRC/Github: @xdg >>> >>> >>> >>> >>> -- >>> David Golden <x...@xdg.me> Twitter/IRC/Github: @xdg >> >>