Front page | perl.perl5.porters |
Postings from July 2014
* Neil Bowers <neil@bowers.com> [2014-07-30 11:30]:
> Skimming perlmodlib here's a first attempt at a list, roughly ordered
> by strength of claim:
>
> 1. Needed to install perl. Eg various Test::*
> 2. Modules (especially pragmata) that are considered to be part of the language. strict/warnings/Carp
> 3. Toolchain modules needed to bootstrap your environment. Eg CPAN
> 4. Modules for talking to your environment / glue. Eg Cwd, Fcntl, File::Spec*
> 5. Codifies best practice in a way that's seen as a good thing ("everyone will/should want to use it"). autodie?
> 6. "Batteries included" - stuff that "everyone" does, so makes sense to come in the box. Eg Getopt::Std, HTTP::Tiny
>
> Some modules tick multiple boxes, which in some sense gives them
> a stronger claim. Though if you're in the first group, it doesn't
> matter whether you tick any other boxes.
There is a movement to get away from #5 and #6, but especially #6 is now
considered a bad idea. E.g. autodie is more of a proposed addition to #2
than part of #5, and HTTP::Tiny is part of #3, for which your definition
is incomplete – the group includes not only toolchain modules themselves
but, of course, their dependencies as well. That is why HTTP::Tiny is in
core.
It is also an example of modules designed specifically so they can be
included in core as a dependency of a toolchain module. CPAN.pm can use
wget or lynx or curl, but those are not necessarily available across
every platform perl supports, so perl had to be able to speak HTTP all
by itself.
And nobody was going to consider LWP for core.
There have been other cases like this; e.g. Parse::CPAN::Meta started
life as a rebranded YAML::Tiny, because of the need to parse META.yml
files. (It may still be that, or it may in the meantime have diverged;
I am not up to date on that.) (The reason for the naming was to avoid
advertising any YAML support, since there were several controversies
there.)
But by and large, the contemporarily accepted reasons to have something
in core are just #1 thru #4; not #5 or #6. There is only some exception
for things that were already in core before adoption of the contemporary
point of view, that could be considered to have been grandfathered in.
Time::Piece is among those. There is no guarantee for any of them that
they will not eventually be ejected from core.
In fact there is really no longer a guarantee of that for any module,
except the ones in the #2 group.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next