Lady_Aleena has asked for the
wisdom of the Perl Monks concerning the following question:

As some of you know, I'm doing an audit of my code. Part of that audit is finding what modules my modules use and what modules I have written are used by other modules I have written. If I ever get things nice enough in some of my modules, I might one day put a few up on CPAN. However, I need to know what modules my modules use so I can include them in the install if the user does not already have. Like, if I use Lingua::EN::Inflect in a module (or group of modules), it would need to be installed if the user does not have it already. At least I think so.

I came up with the following code to find the information but there might be a better way.

update: d'oh! Another reminder not to post before first coffee of the day; my example below will not work in OPs case, as the modules are not yet on the CPAN :) Works well for those that are though.../update

Here's a modified version of a script I wrote that allows me to see if I have any of my distributions on the CPAN where I need to do required module version bumps in my Makefile.PLs for the required modules where I'm the author (original is here). It uses MetaCPAN::Client to do the hard work. Given a module name, it prints out its dependencies, as well as the reverse dependencies (which other modules use it. In CPAN speak, that's "upriver").

In this case, the module is hardcoded for the example, but pretty trivial to make it an argument.

That's a handy script to keep around for sure. It might be worth pointing out to those not in the know that MetaCPAN::Client acts only on the meta data. That is, it will only report dependencies of a module which the meta data of that module declares to be dependencies. Such a list is not always correct, up-to-date, complete or even (in some cases) present at all.

For example, B::Tree uses GraphViz but doesn't declare this in its metadata, so using MetaCPAN::Client you would think it had no dependencies at all. B::Tree is far from being alone in this. The good people at CPANTS provide some statistics for this particular type of error on the part of module authors/maintainers. You'll see some of the modules on that list are recent releases and some by authors you might expect to be on top of such detail so it's a very easy human error to make. Module maintainers can always use something like Test::Prereq to help keep the dependency lists up to date.

For an end user looking to find dependencies, the lesson is to take the metadata with a pinch of salt.