develooper Front page | perl.perl5.porters | Postings from September 2012

Re: Taking CPANPLUS out of core

Thread Previous | Thread Next
David Golden
September 29, 2012 10:29
Re: Taking CPANPLUS out of core
Message ID:
Thank you, Sawyer for figuring all this out.

> Firstly, modules used only by CPANPLUS or CPANPLUS::Dist::Build:
> * File::Fetch
> * Term::UI
> * Module::Pluggable
> * Object::Accessor

I mildly favor keeping File::Fetch, because it is the effective answer
to "why can't Perl open URI's".  It's a very nicely maintained
abstraction layer over a whole lot of mess.

I'm neutral to negative on Module::Pluggable.  I think it has some
risks associated with it and giving it the "Perl Core Stamp of
Approval" isn't ideal.

The others can go as far as I'm concerned.

> Secondly, modules used by those modules:
> * Log::Message::Simple (used by Term::UI)
> * Log::Message (used by Term::UI, Log::Message::Simple, CPANPLUS)
> * Module::Loaded (used by Module::Pluggable, CPANPLUS)

I favor keeping Module::Loaded (along with Module::Load::Conditional
and Module::Load).  Having a nice core API to do the sort of thing
people often screw up messing with %INC or eval/requires make sense.
Even if there are "better" modules on CPAN, I wouldn't favor churning
these out in favor of replacements, because I think that's a lot of
hassle for relatively little gain.

Log::Message can go as far as I'm concerned.

> Thirdly, those that required more research:
> * Locale::Maketext::Simple (used by Params::Check, Archive::Extract)
> * Params::Check (used by Archive::Extract)
> * Archive::Extract (used by CPAN - but not hard dep, only as an extra
> feature: 'gitify')
> * Module::Load::Conditional (mentioned in Parse::CPAN::Meta: Changes file
> indicates "removed M::L::C dependency")
> * IPC::Cmd (mentioned in Module::Build: Changes file indicates "Fix test
> failure if IPC::Cmd not installed")

I misspoke on IRC about Archive::Extract and CPAN (I had meant
Archive::Tar); there is no related reason to keep it.  Much as
with File::Fetch, I still mildly favor keeping Archive::Extract anyway
as it's a nice abstraction to a common, complicated problem.

I favor keeping IPC::Cmd, if only for "can_run", which again provides
a nice platform-agnostic abstraction to something complex that is easy
to get wrong.  I think the rest of IPC::Cmd is dubious and only works
as promised with IPC::Run and with platform limitations. I wouldn't
cry if it were replaced with an IPC::Cmd::Tiny with only the "can_run"
function, though that's again a lot of churn for no real benefit other
than "purity" of core.

I'm neutral to negative on the rest.  I'd even be willing to see
Archive::Extract go just to lose Params::Check.

Why do I want to see so many things go?  Because every dual life
module adds mild, incremental size and work to the core.  I prefer a
smaller core, with libraries that have widespread applicability.
Cleaning house not only has mild benefits, but it also sets a higher
bar for bringing modules *into* core in the future.


David Golden <>
Take back your inbox! →
Twitter/IRC: @xdg

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