Update to review of Dependency modules

I've updated my review of modules for getting dependency information. The previous version listed 8 modules on CPAN — it now covers 18 modules!

The following modules have been added:

  • App::FatPacker::Trace
  • Devel::Modlist
  • Devel::TraceUse
  • Dist::Requires
  • Module::Extract::Use
  • Module::Info
  • Module::Overview
  • Module::PrintUsed
  • Module::ScanDeps
  • Module::Used

One of the recommendations has changed: if you want an approach based on parsing, I'd now go with Module::Extract::Use rather than Perl::PrereqScanner. There's not much between them (both use PPI), but Module::Extract::Use returns a bit more information.

Given I'd missed 9 modules in my first scan of CPAN, and then missed 2 on my thorough search, I wouldn't be surprised if there are still a few to add...

Update 2012-08-27

Indeed: I've now added Module::Inspector, Module::ParseDeps and Module::MakefilePL::Parse, bringing the total to 21 modules. I also updated the section on Devel::TraceUse, following email with Philippe Bruhat.


Have you considered App::FatPacker or App::FatPacker::Trace?

App::FatPacker uses App::FatPacker::Trace to do the tracing job. You could use either one. You can use either. If you use ::Trace, you'll need to run a new instance for it (using $^X for example) and if you're using App::FatPacker you'll simply need to capture it somehow (backtics, Capture::Tiny, etc.)

Here is an example using plain FatPacker:
perl -MApp::FatPacker -MCapture::Tiny=:all -E'say capture { App::FatPacker->trace( args => ["eg.pl"] ) }'


Small correction: App::FatPacker's author is actually mst (Matt S. Trout), not Karen Etheridge. Karen had contributed (as did other people such as David Leadbeater and myself) and released a version.

I think it really boils down to one of the two approaches. Either you run the code and see what Perl has loaded, or you parse the code. One is more appropriate for some cases than the other, and both have strengths/weaknesses. Currently I prefer the second. For example, since I nowadays put "require Foo" inside subroutines or conditionals to delay loading as much as possible, the first approach will miss many dependencies. On the other hand, modules using the second approach will probably always miss cases like modules loaded through DBI->connect, some plugin system, or dynamically via eval/variable.

Perhaps this can be explained in the article, I personally prefer at the beginning.

Just my 2c.

Ah yes, of course, thanks for the correction. I was thinking from a CPAN author's prospective when building his/her dist (including its metadata).

It's simply a difference between "who released it" and "who wrote it". It will probably not be easy to bridge in MetaCPAN because there's a lot of concepts for authorship such as "original author", "current maintainer", "multiple authors", "contributors", etc.

Leave a comment

About Neil Bowers

user-pic Perl hacker since 1992.