in reply to Finding what modules use and what uses the modules

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.

use warnings; use strict; use MetaCPAN::Client; my $c = MetaCPAN::Client->new; my $dist = 'Mock::Sub'; check_deps($dist); rev_deps($dist); sub check_deps { my $dist = shift; $dist =~ s/::/-/g; my $release = $c->release($dist); my $deps = $release->{data}{dependency}; print "Dependencies:\n\n"; print "$_->{module}\n" for @$deps; } sub rev_deps { my $dist = shift; $dist =~ s/-/::/g; my @revdeps; my $rs = $c->rev_deps($dist); while (my $release = $rs->next){ push @revdeps, $release->distribution; } print "\nReverse Dependencies:\n\n"; for (@revdeps){ s/-/::/g; print "$_\n"; } }


Dependencies: perl Carp Scalar::Util Test::More ExtUtils::MakeMaker Reverse Dependencies: Devel::Examine::Subs File::Edit::Portable RPi::DigiPot::MCP4XXXX Test::BrewBuild App::RPi::EnvUI Devel::Trace::Subs PSGI::Hector

Replies are listed 'Best First'.
Re^2: Finding what modules use and what uses the modules
by hippo (Bishop) on May 28, 2017 at 09:57 UTC

    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.