Front page | perl.perl5.porters |
Postings from April 2010
Re: Slim core, battery suppliers [was: Try::Tiny in Core?]
Thread Previous
|
Thread Next
From:
Aaron Sherman
Date:
April 7, 2010 01:28
Subject:
Re: Slim core, battery suppliers [was: Try::Tiny in Core?]
Message ID:
y2zf7d82c901004061555k5f217d52id28b8ede63732672@mail.gmail.com
On Tue, Apr 6, 2010 at 9:07 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com>wrote:
> On Mon, Apr 5, 2010 at 19:54, Aristotle Pagaltzis <pagaltzis@gmx.de>
> wrote:
>
> If we put out 5.* saying "We're slim now. You can install this slim
> core + old libraries from classic.tar.gz or (and we really recommend
> this!) lots of Moose/POE/DBI/etc. sugar from chocolate.tar.gz" someone
> at say Apple might react to that as "Thanks but no thanks, we'll just
> take classic.tar.gz, we have no interest in providing anything but
> bare-minimal Perl support anyway".
>
> Even worse, they might decide that they don't really need any
> libraries, all they use Perl for anyway are these 500 perl4-era
> scripts that are part of the core OS. Dropping classic.tar.gz just
> saved us 5MB on the install CD!
>
That's going to happen. I think we need to get over it.
Platforms like modern Linux distributions get a Perl install that's capable
of doing what the OS needs it to do and then any applications that rely on
some other libraries can simply depend on the platform-specific packages
that they need and they'll be pulled in. There's no real problem there...
The problem arises when a platform doesn't provide advanced dependency
resolution of this sort. Worse, on some (dare I say, legacy) platforms Perl
is strictly after-market (e.g. Windows). On these platforms, anything that
the release du jour doesn't install with is nearly unobtainable for someone
packaging software for use by others. Then the worst case gets even crazier
if you assume that, for example, Google App Engine might ever release their
Perl implementation (http://code.google.com/p/perl-appengine/).
So... I think that the fundamental problem with CPAN vs "core" right now is
that there's just that one level of granularity. The Perl community
basically says, "here's everything you need... oh and some other stuff, but
we won't give you any hints about that."
I think that Perl would be better off differentiating "core" from "valuable
domain-specific features," and then expanding that latter category
substantially, providing the same level of support for a fully
pre-compiled/ready-to-install support for them as the nominal core.
For example, what if we identified several key domains into which modules
fall, and for each domain, specify a unique (but possibly inter-dependent)
set of modules that might aid a developer targeting those domains if and
when a best practice has taken shape.
This would help Perl to integrate with distributions and platforms by
allowing them to exclude many of these domains from their default installs,
and yet immediately pull them in when the user selects an appropriate
install type (e.g. if you say you want a "Web development" install, it
should pull in the Perl "WWW" domain which might in turn pull in the "OO",
"Database" and "Text" domains).
Right now, the antagonistic relationship between Perl's forever increasing
"core" and the platform maintainer's desire to keep the default install in
check is bad for everyone. Doing this would be a major step toward resolving
those tensions, though I'll admit that that first step is a doozy, requiring
all platforms to come to terms with the fact that many assumptions about
what facilities a default Perl installation will require are now invalid.
That might mean that the most sensible first pass is to take the existing
"core" and move it out into these domain pieces. By keeping an exact 1:1
mapping between old core and new core+domains you let folks like Debian
(just an example) ease into the idea by continuing to distribute everything
at no added cost (it's all the same stuff). Then, as packages ease into
this, Perl can begin to expand each domain as appropriate, letting platforms
decide how to respond, secure in the knowledge that their packagers have had
time to work out the new realities of dependency management for Perl.
Side note: Python has this problem as well. They have a PEP (their standards
track) that describes how modules get into the core, but it never touches
the idea of how you constrain the core from turning into a
ship-it-with-everything mountain of code other than the implicit assumption
that somehow Guido will solve that problem using his BDFL magic powers.
Indeed, my local Python 2.4, 2.5 and 2.6 /usr/lib trees are radically
different in size and looking over Ubuntu's packages for 9.10, python 3.1 is
closing in on about twice the size of 2.4.
But Perl was the first language to build a dependency managed Internet-based
distribution and archival system for its universe of libraries. I think it
makes sense for it to also be the first to solve the "core modules" or
"standard library" problem.
--
Aaron Sherman
Email or GTalk: ajs@ajs.com
http://www.ajs.com/~ajs
Thread Previous
|
Thread Next