|Syntactic Confectionery Delight|
Challenge: CPAN Golfby shmem (Canon)
|on Jan 08, 2008 at 12:43 UTC||Need Help??|
Sometimes I just want to try out a module; sometimes I just want to help somebody facing trouble using it. So I fire up cpan and install it, automatic dependency installs turned on. WHOA! follow, follow, follow installing dependencies, and after an hour or so and several fails resolved, I have the top level module ready to use.
Four dozens of intertwined dependency modules installed, another 10 megs of disk space gone. After all, disk space is cheap, no? And those modules are really needed by the top level one, aren't they? (But then there are all those Test::Tester, Test::Tester::Bestertester, Test::Tester::Bestertester::Helper modules and their dependencies as well.)
Then I install the otherwise fine CGI::Ajax module and note it uses Class::Accessor to generate setters/getters for a list of seven object attributes, trading 29 lines of trivial hand-written code against 874 lines or 48 kBytes. That can easily be shrugged off, because other fine modules use Class::Accessor as well - and 900 lines of code don't really count. But it sums up.
This kind of laziness places the burden of installing and updating dependencies, which are not crucial for the functionality of the module in question, on the module user.
And on the long run, we might end up with CPAN modules being blobs that pull in a multitude of modules of which only a minuscle part will ever be used at runtime.
IMHO, hubris beats laziness for module authors, and modules should not depend on other modules if the latter only bring small benefits.
So here is the challenge (draft :-)
So you can't just make up a module that uses all CPAN modules and upload that to CPAN; likewise, building a meta-package (e.g. perl-CPAN-all.deb) and installing that doesn't count.