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

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

Thread Previous | Thread Next
Neil Bowers
July 31, 2014 17:09
Re: Criteria for becoming/dropping a core module [was: Re: maintainer wanted: Time::Piece]
Message ID:

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)
  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.

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.

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.



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