develooper Front page | perl.perl5.porters | Postings from July 2014

Re: Criteria for becoming/dropping a core module [was: Re: maintainerwanted: Time::Piece]

Thread Previous | Thread Next
Reini Urban
July 31, 2014 22:31
Re: Criteria for becoming/dropping a core module [was: Re: maintainerwanted: Time::Piece]
Message ID:
On Thu, Jul 31, 2014 at 6:51 AM, Neil Bowers <> wrote:
> On 30 Jul 2014, at 16:09, Jarkko Hietaniemi <> wrote:
> Time::Piece was an attempt in ["best practice"]
> Though I'd like to squeeze in #4.5... "modules where tight bundling with
> core is necessary/useful", like the B::
> I'd be all for squeezing out all that do not pass #1-#4.  But backward
> compat: at what release would we set the "grandfather line"?
> So my updated hierarchy, given some of the comments yesterday:
>   1. Needed to install perl (Test::Harness)
>   2. Considered part of the language (strict/warnings)
>   3. Toolchain modules needed to bootstrap your installation (CPAN

+ ExtUtils:: of course

>   4. Dependencies for any of the above (HTTP::Tiny)
>   5. Modules for talking to your environment (Cwd, File::Spec*)
>   6. Developer / introspection (B::, Module::CoreList)
>   7. Codifies best practice / language extensions (autodie)
>   8. "Batteries included"
> Feels like there's strong agreement on 1-6, but not on 7, and definitely not
> on 8.

Just a warning:
I'm currently working on Perfect::Hash and friends, needed by
a new unicode table mapper (icu-like, not perl like), CPAN, and some
more stuff (Encode and most bigger XS modules), and this would also
need to go to core then under #3.
So I'll divide it soon into non-core/core parts based on deps and license.

> This made me wonder: what are the most-used modules (on CPAN) that aren't in
> core? They would be candidates for 7 and 8 above.
> Here's the top 20:
> Test-Pod                  3480
> Moose                     2321
> Test-Pod-Coverage         1981
> libwww-perl               1816
> URI                       1432
> Pod-Coverage-TrustPod     1374
> Test-Exception            1266
> Test-CPAN-Meta            1225
> JSON                      1057
> HTTP-Message              911
> namespace-autoclean       824
> perl_mlb                  781
> DBI                       770
> Try-Tiny                  752
> Moo                       701
> DateTime                  683
> List-MoreUtils            668
> Class-Accessor            649
> Dist-Zilla                619
> Path-Class                578
> Some of those are definite "oof, no way *that* is going in core". And I'm
> repeatedly surprised that DateTime isn't in core, but then again I'm not.
> The two that feel like the easiest candidates are URI and Try-Tiny, but most
> people reading this would pick a different 2 from the list :-)
> Some good points in the article that Rik referenced[1]. For example:
> Programmers are reluctant to write libraries that duplicate [core
> libraries], so poor libraries in the standard set persist. Only a few people
> [...] are willing to write modules that compete with the standards.
> I don't think we have the problem of people not writing competing modules
> (I'm working on a review of Exporter modules, and there are 44 I've found so
> far!), but more that modules don't get widely used, because they're not in
> core. This is particularly true for things like Exporter modules. Bringing
> in fresh modules to compete with things already in core might not be a bad
> idea, in moderation.

I'd like to see that also, because we are also switching to some
Exporter sooner
or later, and so far the only acceptable solution is Panda::Exporter,
but haven't
check it deeper yet. Code is either using B, which creates a huge
dependency tree,
or is too big and slow by itself to be useful. Having a non-useful
version in core
definitely does not help.
Having a proper Sub::Name in core (with getter and setter, not the current one)
would definitely help. But ether took it, so I have no idea what the
current plan is.
Lot's of names are flurring around for 3 lines of XS code implemented in bad
100 lines of pure perl.

> But as I go through more exporter modules (and look at their code, xdg!), I
> think "yeah, this one's got some good points, but ..." (no, I haven't got to
> Exporter::Tidy yet, Yves :-). Maybe I'll hit one where I think "perfect,
> here's the one to add to core!", but to be honest I'm not expecting that.
> Writing a module *for core*, like HTTP::Tiny was done, seems like a good
> approach to keeping core moving forward and bringing in modern thinking /
> practices, without bloating. The article also points out that "Once a
> library is enshrined in the standard set, it can’t change radically because
> too many programs rely on it", which strongly applies to Exporter modules:
> you can extend but you can't change incompatibly.
> Neil
> [1]

Reini Urban

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About