Module::Metadata is confused by Fatpack archives

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.

Reproduce the report with Module::Metadata->new_from_file("App/cpanminus/fatscript.pm") and inspect package_versions_from_directory(), including its find() and wanted handling. Trace how the fatpacked file and its POD examples enter the results, using the App::FatPacker-generated fatscript.pm as the case to understand. Done means fatpacked embedded modules and POD example names are handled according to a clearly defined default or opt-in behavior.