In this post, I pointed mt2k to Date::Manip as a potential solution to his problem. He commented that he thought Date::Manip was a standard module. Frankly, I'm a bit surprised that it's not, given that it's functionality is so useful. Other things such as Bone::Easy are not standard modules for ... uh ... obvious reasons.

What exactly are the criteria for a module to make it into the standard distribution? For example, I have no idea why the English module is in there, since it is so rarely used (and disdained by many programmers).

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: Standard Modules
by extremely (Priest) on Jan 03, 2001 at 11:53 UTC
    The keys to getting a module in the distro are many and varied.
    • Some one in p5p must champion the module.
    • p5p must be convinced that it is generally applicable.
    • Larry must be so convinced, as well =)
    • The module needs to we WELL tested on weird platforms and under odd conditions.
    • You have to justify that its value is greater than its size, since you are forcing everyone who uses perl to download it.

    In addition, pure perl is easier to pass through p5p since XS code and C code is notoriously harder to make platform independent.

    As to the suggestions, Date::Manip is huge and fugly, many people hate it and there are a lot of smaller and more focussed modules out there. It would be hard to convince p5p to champion it.

    DBI is useless by itself since you have to have DBD drivers and other DB dependencies to make it work. Why include half a solution when you still have to download what you want. Loading it and a generic SQL engine in perl and DBDs for CSV and DB_FILE and such might pass but it is a lot of code for a tool people will mostly avoid when working with the weak DBs.

    It wouldn't suprise me if Parse:RecDescent made it into core one day. If more and more other modules grow to depend on it, it likely will.

    LWP and Net:: are just too big and many many sites never touch them. I am still suprised CGI made it, once upon a time there was a great backlash against branding perl merely as the "CGI Language".

    In Storable's case, it isn't generally known or used nearly as much as it could be. Also, isn't Data::Dumper in core and _debatably_ used for many of the same porpoises, however fishy they are?

    Neither POE nor Time::HiRes are for the faint of heart. =)

    Finally, English is in there because it is a small and 'useful' for writing easily understood scripts. I call it the "book" module since it makes scripts in books readable. It is small and painless to include.

    --
    $you = new YOU;
    honk() if $you->love(perl)

Standard Modules?
by footpad (Abbot) on Jan 03, 2001 at 02:29 UTC
    As a follow-up question...

    Given the general advice that CPAN modules should be used as much as possible, are there other modules that should be part of the "well-rounded" Perl installation, modules like Date::Manip that aren't part of the standard distribution?

    I realize that certain considerations need to be taken into account (such as the platform, the way Perl is being used, and so on). I'm looking more from a general sense and interested in how your mileage has varied.

    --f

    Update: Via CB, someone suggested DBI. Other thoughts/reactions?

      Some modules/bundles I habitually install on new systems: The first three are, in my opinion, perfect candidates for core distribution. The latter three are really kind of large and probably would be best left as independent packages/bundles.
        Ok, I've tried reading the docs, but I guess I've been away from coding for too long to be smart enough to "get it"... what does POE do? What have any of y'all used it for?

        There was a Perl 6 RFC being drafted at one point that suggested moving Symbol::Approx::Sub to the Perl core.

        Luckily the authors sobered up before they submitted it :)

        --
        <http://www.dave.org.uk>

        "Perl makes the fun jobs fun
        and the boring jobs bearable" - me

      Just as a sidenote it is easier to get perl into production here than it is CPAN modules.

      The more robust the standard modules are the less haggling with security and sysadmins is required.

      coreolyn

Re: Standard Modules
by salvadors (Pilgrim) on Jan 03, 2001 at 01:42 UTC