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"] ) }'
Wasn't aware of that - will add it in the next update. Thanks Sawyer.
Have added App::FatPacker::Trace to the review, along with Devel::Modlist which Kirk Kimmel pointed out to me.
Awesome!
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.
Thanks Sawyer. The module summary table is constructed automatically, using info from metacpan and other places. MetaCPAN reports Karen as the author. I've raised this with MetaCPAN, and I guess may end up reporting a bug :-)
There are three approaches Steven (the other one being to pull together info from metadata files), but that's a good suggestion. I'll have a go at the introduction later.
Not a bug: I just need to add an extra hop: given a module, get the dist, get the dist's metadata, and the true author will be listed. Which is no doubt going to change the attribution on a lot of modules in review tables.
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.
Ended up having a chat about this on #metacpan. Castaway pointed out 06perms.txt, and we ended up discussing how this might be included in MetaCPAN, so you could get it from the /release endpoint, for example.
Steven: I added the summary of the three basic approaches, in the introduction as you suggested. Thanks. There are so many modules now that I think some kind of map is required for the Comparison section. I'll have a go at that for the next update.