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:
Jarkko Hietaniemi
Date:
July 31, 2014 22:35
Subject:
Re: Criteria for becoming/dropping a core module [was: Re: maintainerwanted: Time::Piece]
Message ID:
CAJuepptaWMWvFRyTH+sMt_bYgDkMX8Rkz3Rp4hV7XCYxCOZeTA@mail.gmail.com
<pythonenvy>Mersenne Twister in "core"</pythonenvy>
On Thursday, July 31, 2014, Reini Urban <rurban@x-ray.at> wrote:
> On Thu, Jul 31, 2014 at 6:51 AM, Neil Bowers <neil@bowers.com
> <javascript:;>> wrote:
> > On 30 Jul 2014, at 16:09, Jarkko Hietaniemi <jhi@iki.fi <javascript:;>>
> 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/
>
--
There is this special biologist word we use for 'stable'. It is 'dead'. --
Jack Cohen
Thread Previous
|
Thread Next