Open demerphq opened 1 year ago
I don't entirely follow what's going on but the steps described (generating MYMETA from META) are only relevant on installation, where the metadata is no longer useful.
(that is to say, the only relevant fields of MYMETA as opposed to META are the dynamically generated prerequisites if any.)
I don't know where your 'license' => [ 'perl_5' ],
comes from but I can't reproduce it. It's 'unknown'
all along for me
I was working on a BBC ticket for perl, https://github.com/Perl/perl5/issues/20864 and I noticed that it complained that the LICENSE value from the Makefile.PL was invalid. The value is/was "perl_5", which as far as I can tell is a valid value.
So I started digging into it. Eventually I found my way to ExtUtils::MM_Any::_fix_metadata_before_conversion(). I instrumented the function to dump out its arguments and cluck a stacktrace when it was called, and it seems to get called twice. Once from metafile_target(), and once from write_mymeta().
In the first call the license value is recognized as correct, and things look (to me) to be correct. On the second call however things look much different, actually downright strange, and the license is not recognized and turns into "unknown". The second call seems to be responsible for generating the MYMETA.yaml and MYMETA.json files and both say the license is "unknown". Furthermore they both say this:
note that this is from a perl that was built from blead a day ago, with ExtUtils::MakeMaker 7.66.
Here is the instrumented output:
Notice the first output says
LICENSE field no longer honored properly. but the second says
as was found in the MYMETA.yaml files on disk. If I delete the META.yml file from disk before I run Makefile.PL then I no longer get the complaint about an unknown version, and the generated files now look "correct".
It seems to me that we end up keeping way too much of the META.yml on disk than we should, with the result that we end up ignoring things that were passed into WriteMakefile.
I am a bit lost on what to do to fix this, but it sure feels like we give the old META.yml too much priority, and that we produce really inscrutable errors when this happens. Now that i understand things a bit it seems I should just get the META.yml removed from the repo for this module. But frankly this was really confusing to debug and understand. I think we should warn that the META.yaml is really out of date in a situation like this.
FWIW some of my current understanding of this bug came about while I was writing this report. Sorry if it is a bit stream-of-consciousness.