CPAN modules that (can) load other modules

I've published a review of CPAN modules that (can) load other modules. I started making this list of modules when looking at modules for getting dependency information: one class of such modules parse code looking for things that signify a dependency, either implicitly or explicitly.

There's still a fair bit to do, I've got a number of pull requests and offers to release updates outstanding, and no doubt I've missed some modules.

pp+1.pngIf you enjoyed this review, you could give me a +1 on the play-perl quest for this review.

Updates


16 Comments

Hi Neil

Marvellous, as always.

Some comments:
1) Where you say Mojo::Loader "will only find modules where the .pm file is immediately within the namespace specified", you could add that that is good from a security point of view.

2) Using a spreadsheet of module name 'v' capability would help convey the complex combinations you mention.

Ron

You can use Module::Implementation for more than just Pure Perl or XS. It's useful any time you want to provide a given interface with 2+ possible backends.

For example, you might try loading different per-OS implementations of an API (like inotify vs kqueue). And it will work fine with more than 2 implementations.

You haven't mentioned only.pm.

It's recommended in PBP and there's an article (http://www.perl.com/pub/2003/03/18/only.html) describing it in glowing terms. It was obviously expected to be the next big thing at one point.

I've often wondered why it never caught on.

The author has clearly lost interest in it and it currently fails over 500 tests on CPAN, so I'm definately not using it at the moment!

You forgot Acme::require::case. ;-)

You also might want to mention the security risks inherent in bad implementations of module loading, as Schwern references in http://blogs.perl.org/users/michael_g_schwern/2011/10/how-not-to-load-a-module-or-bad-interfaces-make-good-people-do-bad-things.html

if.pm, a core module, is also missing from the list.

Thanks for including Module::Quote/Module::Hash in there.

A little background... Module::Quote is an experiment based on the idea of a sigil for package names as mentioned by chromatic. Sigils are hard to implement outside core; quote-like operators are more doable. It achieves some of its aims - it resolves a technical ambiguity (Math::BigInt->new will only return a new Math::BigInt object until somebody defines a BigInt() function in the Math package), and helps make "different things look different".

Module::Hash is weirder, I grant you. It's basically the half-way point on the way to Module::Quote. It's less magic, and has lighter dependencies. I prefer Module::Quote though.

Tied hashes work by associating a Perl hash with a blessed object. Module::Quote uses blessed Module::Hash objects, but doesn't tie them to hashes - it just reuses Module::Hash's logic for splitting module name and version, adding an optional module name prefix, etc.

Hi

blogs.perl.org just ignores any attempt to click the Reply button, so I'm replying at the end....

Good for security because restricting the # of places a modules is looked for limits the possible places where a hacker could install a module and then trick Perl into loading it.

Hi

As for showing the space, I was thinking that given a spreadsheet, I (or other) could write code to generate a Graphviz image with edges linking module names to concepts or ideas. This would a different way of visualizing the connectedness or set of functionality offered by a module, one which might be clearer for some readers.

Leave a comment

About Neil Bowers

user-pic Perl hacker since 1992.