Ever since I first tried to write one, the Bundle:: modules have annoyed me.
They ignore your Makefile.PL, use a magic POD format, require special implementation in the CPAN clients, are now LESS functional that the normal installers from Module::Install or Module::Build, and are cludgy to impossible to use outside of CPAN.
They are also confusing for newbies, and I've met a few people that intitially assumed that the actual dependencies were somehow "bundled" into the dists.
I've wanted to replace Bundle with something more sane for a while, but the main problem has been the Bundle:: itself is detected and abused automagically by it's namespace, with the "Bundle" string itself triggering internal logic, so having a replacement would involve moving to another namespace.
Do you have any idea how hard it is to pick one. It stumped the modules@perl.org mailing list when I asked... just consider the potential confusion from any of these potential replacements.
Collection::
Batch::
Assembly::
Bunch::
Set::
ModuleDependencySet::
etc
etc
In fact, the enterprising person who suggested Bunch:: did a thesaurus search for Bundle:: and Bunch:: was the ONLY one that didn't already have some form of alternative meaning.
So today it finally occured to me that an equivalent to what Bundle:: does already exists, in the form of the "task" series of debian packages.
These are just normal-looking-packages with a bunch of appropriate dependencies, and with the ability to have something custom in the installed if you want.
And so I'm introducing Task:: as a successor to Bundle::
A Task:: distribution has ZERO special or magic functionality.
Rather than a .pod file, a Task:: module has a normal .pm with no code and just a $VERSION, and POD describing what it does, so that if you really want to, you can still load Task::Foo in in your program and check that it's $VERSION is new enough to match what you want.
The dependencies are implemented in the Makefile.PL/Build.PL as normal, and you have all the normal access to optional modules or checks for system tools. You can add an extra module dep on Win32, or even use test scripts.
You can pack up a private Task:: distribution and email to a sysadmin to make sure he installs the correct modules you need for your CGI application.
Task:: is a case of replacing a special feature with just a convention, and gaining more power and flexibility in the process.
I've provided what I hope is enough documentation in Task itself, and if anyone wants to see an example of a Task distribution for a web application, see Task::CVSMonitor for an example. (grab the dist tarball itself and look inside)
If the Task modules haven't made it to search.cpan yet, they should shortly.
I'm not suggesting that everybody go out and convert their Bundle:: modules straight away, but the option is now there if you want it.
To forward port a Bundle:: to a Task::, create the Task::Foo dist, and then alter the Bundle::Foo dist to load Task::Foo and nothing else.
Comments are welcome. However anyone who doesn't like Task:: should suggest a better alternative, because I'll be damned if I can't think of anything better :)
Only one comment: great!
Re:BundlePLUS?
Ron Savage on 2005-11-30T05:23:26
Yes, good idea.
But the name is appalling.
Try:
o Briefcase
o Satchel
o Fist (in English we can say 'Make a fist of it':-)
o Ingredients
o PerlBase
and so on.Re:BundlePLUS?
Alias on 2005-12-02T09:06:39
Except that Bundle doesn't really "bundle" the modules either. Things like PAR "bundle" the modules into the package.
All these other suggestions aren't great either, and therein lies the problem.
The main things Task has going for it is that it is at least closer to what a bundle currently actually is than "Bundle", it's better English that something like Satchel so that non-native speakers won't get confused as easily, and there's a precedent for using it in this way, as a list of other modules to install.
