CPAN modules for getting module dependency information
I've written a review of CPAN modules for getting module dependency information. There are 8 modules on CPAN covered, plus I've included a module I've just written, as none of the ones I reviewed did quite what I wanted.
I've taken a slightly different approach to this review: previously I've spent a lot of time learning about each module, trying to fix any bugs I come across etc, so the first version published is fairly polished. As an experiment, this time I've done a much quicker first pass, and essentially published a first draft. I started off with 6 modules, but two more were pointed out by readers.
I wanted one of these modules for another review I'm working on, where I was curious what all the modules were getting pulled in by some of the modules under review.
Any comments on the review, and identifying missing modules, appreciated as ever.
Perl hacker since 1992.
Hi Neil
Well done - again.
And, how come you didn't include Perl::PrereqScanner?
Cheers
Ron
Hi Neil
While I think of it, I have a home-grown script which uses Perl::PrereqScanner and compares it's output with what's listed in Makefile.PL and the optional Build.PL, so as to report what you've forgotten to specify as a pre-req.
Ron
Hi Neil
Also, as a name for your new module, how about Module::PrereqReport? I think this is better than your temp name because it's shorter...
Ron
Thanks Ron, I hadn't picked up Perl::PrereqScanner. Now included!
I've thought of some other names for the module, but they're all even longer: Module::Dependency::Runtime or Devel::Dependencies::Graph - named for comparison with other modules.
It's a bit depressing there are all these modules which all do the same thing, and none of them seems to be perfect.
I imagine that 95% of people who read that kind of review would just want to get to "which module is best", so I would put that information at the top of the article.
Holy crap, I forgot about Module::Depends::Tree. The CPAN remembers all!
Because perfection, like beauty, is in the eye of the beholder. Depressing, perhaps. :)
You said: "It's a bit depressing there are all these modules which all do the same thing, and none of them seems to be perfect." I'm pointing out that the notion of perfect differs from person to person. Some of those modules are maybe already perfect to some people. How do you define perfect objectively anyway?
Oh Ben!
Here you go saying "It's a bit depressing there are all these modules which all do the same thing, and none of them seems to be perfect", yet just 9 minutes later you commented on Toby's excellent post on filing the perfect bug report saying "My response to this is that I can very likely write my own code to do whatever your module does in less time than it takes me to write a bug report according to your specifications".
That's what makes Perl so good (whipupitude) and is one of the downsides of CPAN (it's often much quicker to roll one of your own and pop it on CPAN than it is to try and work what you want into an existing module).
But having lots of alternatives can prompt good ideas, and sharing of features. There just needs to be a force for convergence. These are the thoughts which started me doing these reviews: so often when I'm looking for a module to do X I find N modules which do some approximation of X, and it's not clear which is the best / right one to use.
Oh, and Ben, just skip the next review I post, that'll really depress you! Twenty modules for making HTTP requests.
Module::ExtractUse can also report dependencies, though it mainly cares for stuff you
use(so it does no mapping of module name to distribution).It's used by CPANTS, and is, as the whole CPANTS, a bit outdated with regards to more modern ways to
usestuff (i.e. Moose et.al.).Giddily looking forward for the grand shootout.
Thanks domm, I've added Module::ExtractUse.
I've also had a bit more of a play with Perl::PrereqScanner. The graphing script I wrote for that would just as easily work with Module::ExtractUse, so I might have a play with that next...