Thanks for the clarification - good to know that my suspicion was correct!
So, the lesson here is: be careful about dynamic prereqs that are keyed off of changable conditions. Requiring an additional prereq based on the perl version or OS is safe, but not on the version of another module, because that module's version could change, rendering the original check invalid. In distributions that are affected by this particular situation, I will respond by simply requiring Dist::Zilla 4.300039 as a hard prerequisite, thereby moving us past the window of uncertainty where invalid metadata is created which may or may not be considered invalid by CPAN::Meta. On Thu, Jun 19, 2014 at 03:01:47PM +0300, Alexandr Ciornii wrote: > Hello > > One of dependencies requires newer CPAN::Meta, so it happens after > Makefile.PL. MYMETA.json does not has Dist::Zilla dependency because > MYMETA.json is generated by Makefile.PL. AFAIK dependencies in report are > taken from MYMETA. > > > 2014-06-17 6:56 GMT+03:00 Karen Etheridge <p...@froods.org>: > > > > > Hi chorny, > > > > I'm puzzled by this test result: > > http://www.cpantesters.org/cpan/report/1df5ee48-6bfd-1014-9e76-6cfddcbe4409 > > > > These failing tests are caused by a mismatch between versions of CPAN::Meta > > and Dist::Zilla. Last year, CPAN::Meta 2.132620 started validating the > > license field of metadata more strictly, and Dist::Zilla was producing > > non-compliant data - which was fixed in version 4.300039. > > > > Consequently, I include these lines in my Makefile.PL: > > > > WriteMakefileArgs{PREREQ_PM}{'Dist::Zilla'} = > > $FallbackPrereqs{'Dist::Zilla'} = '4.300039' > > if eval { require CPAN::Meta; CPAN::Meta->VERSION(2.132620); 1 }; > > > > However, it doesn't look like these lines were run, as I see the versions > > on your test system are: > > > > 2.141520 CPAN::Meta (recent enough to have a strict validator) > > 4.300028 Dist::Zilla (old enough to be producing bad data) > > > > Can you confirm if your test system is properly running Makefile.PL and > > respecting all the prerequisites declared within? I can't think of another > > reason why prereqs would be unsatisfied. > > > > Is the resulting MYMETA.json from this build still available? I wonder if > > that should be dumped as part of the test report, as a way to tell what > > things were upgraded as part of this test run. > > > > > > (One other possible case that could happen in other situations is that > > CPAN::Meta wasn't installed at all when Makefile.PL was run, but another > > prereq caused it to be installed - which would mean the eval line would > > originally fail, but then when tests are run, the version *is* new enough > > to produce an error. However, that shouldn't have happened in this case > > because CPAN::Meta is in core -- although something else could perhaps have > > required a newer version than what was originally installed. There's > > nothing that captures the state of the prereqs *before* they are fulfilled, > > or in between the configure and build phase, so I'm not really sure.) > > > > > > -- > Alexandr Ciornii, http://chorny.net -- "The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive." - Thomas Jefferson . . . . . Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
