NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Bundles are SDKs (Score:1)
That's the reason http://search.cpan.org/modlist/Bundles [cpan.org] is titled "Bundles (and SDKs)". (Of course that only lists 'registered' bundles, but that's a separate issue.)
I'd like to see many more people uploading bundles defining sets of modules that they use. Even better if the bundles define explicit module versions that are known to work together.
Better still if the bundle definition is managed as part of the configuration management of a large company/project that invests testing effort into the bundled modules. For example, companies like the BBC, Vodafone, MorganStanley are all big users of Perl who carefully test and manage sets of perl modules for their own use. It would be useful if those tested sets were published as Bundles aka SDKs.
People with large bundles would make them more useful to others by splitting them up into (possibly overlapping) topic-related subsets: Bundle::TIMB::Database, Bundle::TIMB::XML etc etc. Remember that bundles can include bundles.
Reply to This
*Some* Bundles are SDKs (Score:1)
This is a timely thread, as I was just grazing for modules to recommend for our site_perl libs, and wasn't finding kwalitee or ratings terribly helpful. (Kwalittee doesn't even add a point for removing blah blah blah and a.u.thor@ from template POD!)
Using Bundle::* as the real recommendation will be rather more useful, for some of the Bundles. Those bundles that are personal SDK sets (e.g., Bundle::SDK::PAUSEID) are far more useful as "recommendations" than Bundle::ALLBY::PAUSEID, which some of these Bun
Bill
# I had a sig when sigs were cool
use Sig;