Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35176
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <47A80BE0.4010303@chiaraquartet.net>
Date: Tue, 05 Feb 2008 01:10:24 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Steph Fox <steph@zend.com>
CC: Derick Rethans <derick@php.net>, Marcus Boerger <helly@php.net>, 
 internals <internals@lists.php.net>
References: <01c801c865d8$2e837e90$c6fc1f3e@foxbox> <14581063.20080203002104@marcus-boerger.de> <005201c8660f$66a2b160$c6fc1f3e@foxbox> <alpine.DEB.0.98.0802041032220.10785@kossu.ez.no> <00f501c86743$e5122320$c6fc1f3e@foxbox>
In-Reply-To: <00f501c86743$e5122320$c6fc1f3e@foxbox>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
From: greg@chiaraquartet.net (Gregory Beaver)

Steph Fox wrote:
> Hi Derick,
> 
>> I see another issue after reading this, and that is that it makes it
>> much harder for users to depend on specific extensions just being always
>> available by default. It's important for application distributers to
>> have this core set of extensions to rely on. It's annoying enough that
>> some distributions (gentoo, freebsd) already use --disable-all and their
>> users then bugging us (or me) with "you should check that SPL is enabled
>> in your code".
> 
> Well, you should, while it's possible to disable it!
> 
> Consider a distribution that has _only_ the essentials. Consider also a
> relatively small bundle of PECL extensions that ships alongside it. Say
> we classify them: everything that currently ships with core would be
> class A1 or whatever, as would anything else in PECL that is stable and
> considered likely to be useful to a wide range of users. Anything in
> that bundle is "recommended", and we make it very plain to sysadmins
> that they should install any of that bundle supported by their system.
> It includes things like (most) PDO drivers, SOAP, sqlite, zip, curl,
> json... all things that are currently shipped with the core but not
> necessarily (under doze at least) enabled by default. We educate PHP
> users to insist on 'the A1 pack'. We also make it _possible_ to operate
> PHP without 'the A1 pack', but I do just mean 'possible'. (In other
> words it should be possible to write a basic website using PHP as it
> comes, without adding or enabling anything.)
> 
> If everything in PECL were classified, it'd be much easier for people to
> figure out what to load and when. A simple 'justification' line
> alongside the classification would be immensely helpful, assuming the
> info in package.xml is made obvious via the installer. You'd need a few
> extra sections in package.xml, e.g:
> 
> <version>2.0</version>
> <status>stable</status>
> <classification>
> <rank>A2</rank>
> <reason>specialist interest</reason>
> </classification>
> <maintenance>
> <level>active</level>
> <lastfix>10/01/08</lastfix>
> <bugsopen>5</bugsopen>
> </maintenance>

As a side note, Pyrus development is continuing (will be restarting once
the phar work slows a bit).  There are several things I want to do for
pecl that we don't do now.  Here's the "off the top of my head" list:

1) build_dir - instead of using a random temporary directory for
building, so those temp files hang around, making it easier to
debug/patch (providing "pyrus make-clean" to clean up would be a piece
of cake as well.
2) any changes you all work out like Steph's proposal for additions to
package.xml, although I would recommend instead putting those in a
special file within package.xml that is human-readable and machine
parseable that pyrus would look for, so that the exts can still be
installed by the PEAR installer.

Greg