Open grtodd opened 9 years ago
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.
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 ;-)
Module::Metadata 's
package_versions_from_directory()
is confused by the existence of afatscript.pm
file in the directory being searched. The function pushes modules into the results that are inside thefatscript.pm
: POD examples, etc. Thefatscript.pm
in question comes from from mycpanminus
install and was made byApp::FatPacker
.You can see this if you grab the file explicitly with
new_from_file()
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 byModule::Metadata
somehow on a default run (via the call towanted
in thefind()
frompackage_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.