Module::Metadata is confused by Fatpack archives

[grtodd]

Module::Metadata 's package_versions_from_directory() is confused by the existence of a fatscript.pm file in the directory being searched. The function pushes modules into the results that are inside the fatscript.pm: POD examples, etc. The fatscript.pm in question comes from from my cpanminus install and was made by App::FatPacker.

/home/myuser/perl5/lib/perl5/App/cpanminus/fatscript.pm

You can see this if you grab the file explicitly with new_from_file()

  % cd ~/perl5
  % perl -MData::Dumper -MModule::Metadata -E '
      $pm_info = Module::Metadata->new_from_file("App/cpanminus/fatscript.pm" ); 
      print Dumper \$pm_info ;'

It was suggested that the fatscript code was confusing Module::Metadata by the use of HERE style documents: the output shows "A" "My" "YourModule" etc. which all come from POD examples. Perhaps embedded fatpacked modules should ibe excluded by Module::Metadata somehow on a default run (via the call to wanted in the find() from package_versions_from_directory) and flagged as fatpacked with embedded modules and then either special cased (package_versions_from_fatpack) or the output only available when a constructor option is passed. In any case the incorrectly included POD example modules in the fatpacked file should be handled more correctly.

[karenetheridge]

I think it would probably be reasonable for the caller of package_versions_from_directory to pass a list of filenames (or regexes perhaps, or File::Find rules - details to bikeshed later) to skip over when scanning for packages and versions. You could list fatscript.pm there, or the inc dir, etc.

[grtodd]

I guess that would marginally speed things up too?

Since the "skip list" would be a subset of *.pm files this seems like the easiest "first pass" approach. Of course it would be useful to interrogate fatpacked applications (e.g. those that include something like fatscript.pm) so enhancing Module::Metadata to be able do that correctly - maybe with a separate function like .package_versions_in_fatpack/archive() - would be great. This could make M::M useful to users (or authors?) of App::Fatpacker, App::Packer::PAR, etc. in some way ...

I will add a more useful version of this issue toModule::Metadata's RT.cpan.org bug queue ... eventually ;-)