This was fixed somewhere in/before 0dabab8 and c570eaf, right?

(5.16 and 5.18 are enabled and green on master 😅)

It was worked around by manually listing the deps that need to be installed. It still won't do it automatically for some reason and only on these versions. (It's not just Sub::Util but all deps)

Ah right, sorry I missed that @Grinnz. 🤦

Did some testing locally on 5.18 locally vs 5.20; in both cases, I started with cpanm -n --self-upgrade to help rule out cpanm version inconsistencies (and used the same Docker images the CI is using, FWIW):

$ perl --version | grep 'This is perl' 
This is perl 5, version 18, subversion 4 (v5.18.4) built for x86_64-linux
$ cpanm --version | head -2
cpanm (App::cpanminus) version 1.7044 (/usr/local/bin/cpanm)
perl version 5.018004 (/usr/local/bin/perl)
$ cpanm --showdeps .
--> Working on .
Configuring /cwd ... OK
perl~5.016

vs:

$ perl --version | grep 'This is perl' 
This is perl 5, version 20, subversion 3 (v5.20.3) built for x86_64-linux
$ cpanm --version | head -2
cpanm (App::cpanminus) version 1.7044 (/usr/local/bin/cpanm)
perl version 5.020003 (/usr/local/bin/perl)
$ cpanm --showdeps .
--> Working on .
Configuring /cwd ... OK
perl~5.016
ExtUtils::MakeMaker
IO::Socket::IP~0.37
Sub::Util~1.41

In both cases, I get the same PREREQ_PM output in the Makefile, but the generated MYMETA.yml contents are consistent with the incorrect list we're getting from cpanm --showdeps. To that end, I removed the manual installation of both Sub::Util and IO::Socket::IP and instead added a manual upgrade of both App::cpanminus and ExtUtils::MakeMaker and got the correct result: https://github.com/tianon/mojo/actions/runs/116098123

I'll be opening a PR shortly! 👍

I'm bothered by unexplained "for some reason" statements :) Something is seriously wrong in the toolchain setup if prereqs are not being detected.

Totally agreed! As I noted in #1525 (comment), I did a little testing and found that EUMM version 6.68 is enough to fix it (up from 6.66 included in Perl 5.18). However, when adding CONFIGURE_REQUIRES => {'ExtUtils::MakeMaker' => '6.68'} to our Makefile.PL, it doesn't work, and I'm fairly sure it's falling prey to the same EUMM bug that's affecting our PREREQ_PM. 🤕

Edit: Perl-Toolchain-Gang/ExtUtils-MakeMaker@35ad81b is the specific EUMM commit that fixes it, as far as I can tell.

Note that configure requires are not relevant to MYMETA.json, they would be picked up from META.json before Makefile.PL is even run (so while it may not fix the CI it would be sufficient to fix users running into this case).

the presence of CONFIGURE_REQUIRES => {'ExtUtils::MakeMaker' => '6.68'} in Makefile.PL should put the appropriate entry into META.json, and CI should pick it up from there. (If the CI tools are not reading configure-requires out of META.json before running Makefile.PL, then there are going to be more issues not just with this distribution, but in any dist that does anything "interesting" in their Makefile.PL, for example using Devel::AssertOS or ExtUtils::CheckCompiler.)

In this case there is no META.json stored in the repository because tooling isn't in use that makes that easy and the only use of META.json in the repository is to support configure_requires for CI, which hasn't been needed yet.

ah okay, thanks for the clarification. I thought CI was testing the result of 'make dist', which would have a META.json properly generated, not the bare repository.

Only if it was using a new enough EUMM to run make dist 😐