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.
 | If you enjoyed this review, you could give me a +1 on the play-perl quest for this review. |
Updates
- Added Acme::require::case, if, and only, which I'd missed.
- Improved description of Module::Implementation (thanks Dave).
- Added pkg and UNIVERSAL::require.
Perl hacker since 1992.
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!
Thanks Ron. (1) Why is that good from a security point of view? (2) I've been thinking about something like that, but thought it may be a big sparse matrix, and not very helpful. I'm going to have a play with various ideas for "showing the space".
Dave: I was trying to say that's a common use case, but you're right, it does read like that's all it supports. I'll reword it later. Thanks.
Thanks Duncan, I've added that to my list, and will include it in the first update.
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 https://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
Ah yes, the Acme namespace. I'll add that in the first update. Thanks for the reminder about SCHWERN's post.
if.pm, a core module, is also missing from the list.
Thanks Olivier - now on manifest.
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->newwill 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.
I prefer Module::Quote too — I quite like it. Though it bothers me that it depends on Module::Hash :-)
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.
Five more modules added, thanks for all the pointers.