CPAN::Meta sometimes producing the wrong version MYMETA.yml

[wchristian]

https://gist.github.com/897910

No idea how this could happen, but it occurs on perl 5.12 and 5.10.

Another example- http://www.cpantesters.org/cpan/report/fb27a132-6ce6-1014-a833-e04ea9f09604

[schwern]

I suspect this is a CPAN shell problem, not us. In particular...

Gathering information from index files ...
Populating database tables ...
Done!

is CPAN::SQLite. I suspect that's to blame, probably a bad cache. Disable that and see if the problem happens.

The cpantesters link is the "" version problem.

[wchristian]

CPAN::SQLite. I suspect that's to blame, probably a bad cache. Disable that and see if the problem happens.

Nope, happens without it as well: https://gist.github.com/899405 The very fact that those 3 lines appear means that it generated a fresh cache when i ran it. Did you have problems reproducing it? If so, i could try and run it through my debugger.

The cpantesters link is the "" version problem.

You're right, i mixed that up, thanks.

[schwern]

GD::Barcode::Code93 installs fine here on OS X with 5.12.2. That definitely looks like a CPAN shell issue. MakeMaker clearly spotted the missing prereq with "Warning: prerequisite GD::Barcode 0 not found.". What version of the CPAN shell?

Maybe diff the Makefile?

[wchristian]

CPAN is 1.9456 on that perl and for both of the test cases.

Here's the contents of the build dir with EUMM 6.56: http://dl.dropbox.com/u/10190786/GD-Barcode-Code93-1.4-Fk_n2w.rar (installs fine)

Here's the contents of the build dir with EUMM 6.57_08: http://dl.dropbox.com/u/10190786/GD-Barcode-Code93-1.4-mq3bpw.rar (gives the error above)

[schwern]

Both are producing the same META.yml file, but 6.57_08 is also producing MYMETA.yml with version 2 of the meta spec. The syntax for requires is different. It's possible that the CPAN shell is reading that MYMETA file but expecting the old syntax and not looking at the meta version.

Looking at the code in CPAN::Distribution that's exactly it.

Well this is a problem. I'll have to pull @dagolden and @rjbs in on this to see what we do.

One option is to still produce the deprecated keys to maintain compatibility. CPAN::Meta will have to be altered to do this.

[schwern]

PS I know it's the thing to do on Windows, but sending a Unix user archives that unpack into . is like a pie in the face. :P

[dagolden]

if you are generating MYMETA.yml (YAML) then it has to be <= version 1.4 of the spec. If you are generating MYMETA.json (JSON) then it has to be >= version 2 of the spec. Before version 2, the meta-spec key was poorly defined and there was no requirement that clients actually check the version of the spec. Thus the YAML/JSON split helps ensure that older clients that don't know about MYMETA.json will still get a 1.4 MYMETA.yml that they can deal with.

[schwern]

Long story short: there's a bug in CPAN::Meta->as_string. It's supposed to be looking at the meta version to see if it needs to convert but it's looking at the module version. Since this is version 1.4 it happens to think it doesn't need to convert the META spec from 2 to 1.4.

Thanks David. Something else has gone wrong then. The code in MakeMaker does say MYMETA.yml is 1.4 and I can verify that's what I get. But the MYMETA.yml wchristian sent is version 2.

The other odd part is both META.yml files say they're generated by MakeMaker 6.55_02! MYMETA.json and MYMETA.yml reflect that. But the Makefiles have the correct MakeMaker version. But I guess that's just getting copied from the META.yml file... which is confusing and means we don't know what generated them. @dagolden, that should probably be changed. generated_from should reflect where it came from and generated_by should reflect what generated the MYMETA file.

[schwern]

Reported as https://rt.cpan.org/Ticket/Display.html?id=67188

[dagolden]

2.110930 released to CPAN

[schwern]

@dagolden Thank yooouuuuu!

[schwern]

Upgrade CPAN::Meta to 2.110930 which produces the right MYMETA.yml file

Closed by 707a23cb2a7298c4e005245a2d359230cf886f43

[wchristian]

PS I know it's the thing to do on Windows, but sending a Unix user archives that unpack into . is like a pie in the face. :P

Noted and sorry. It's more of a habit than anything else, really, since Winrar offers the relevant menu option closest to the mouse. ;)

I've actually been hit with this before and never stopped to consider.

Also, thanks to xdg for the quick fix. :D