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
From:
Reini Urban
Date:
July 31, 2014 22:31
Subject:
Re: Criteria for becoming/dropping a core module [was: Re: maintainerwanted: Time::Piece]
Message ID:
CAHiT=DGQsiL==sf4SKOB0sZU_81DQ81ky2ot+V1n=BD+PvrqOA@mail.gmail.com
On Thu, Jul 31, 2014 at 6:51 AM, Neil Bowers <neil@bowers.com> wrote:
> On 30 Jul 2014, at 16:09, Jarkko Hietaniemi <jhi@iki.fi> 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
ExtUtils::Constant,
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] http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
Thread Previous
|
Thread Next