Newsgroups: php.internals,php.pear.dev
Path: news.php.net
Xref: news.php.net php.internals:45005 php.pear.dev:52386
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 209.85.216.176 cause and error)
Message-ID: <4A5FB5B9.9030402@chiaraquartet.net>
Date: Thu, 16 Jul 2009 18:20:25 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>, 
 PEAR Dev <pear-dev@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: better management of php-src/pear and PEAR's future in php
From: greg@chiaraquartet.net (Greg Beaver)

Hi,

I'd like to start a discussion on php-src/pear and how we can manage it
better for PHP 5.3, and to discuss the future of PEAR in PHP.

First, take note that both internals@ and pear-dev@ are copied on this
email.

For some background, currently the pear components are dynamically added
to a checkout by downloading from pear.php.net.  These components are
install-pear-nozlib.phar and go-pear.phar (for windows).  In addition,
the windows go-pear.phar is only downloaded by the build script for
windows.  Although this works, it adds some obscurity to how the process
really works.

I'd like to consider instead using svn:externals to pull in PEAR stuff
directly from a STABLE branch from somewhere in the pear/ hierarchy. 
This would allow us over at PEAR to push the installation phars into
that branch at the same time a release is made, and would also allow
quick fixes by a quick revert to a previous revision.

In terms of the future of PEAR in php-src, now that Pyrus is approaching
its first public releases, I'd like to brainstorm how best to replace
PEAR when the time is right.  Some questions that I have:

1) how important is the backwards compatibility of the "pear" and "pecl"
script commands?  I.e. does Pyrus need to provide a way to emulate the
interface to these scripts or can we break backwards compatibility on
this point by having these scripts just call pyrus's frontend with
default channels pear/pecl?
2) what about php 6?  Any interest in providing Pyrus with php 6? (this
is much more long-term hypothetical than the previous question since few
of you know anything about pyrus.  Pyrus is a PHP 5.3+ re-write of the
PEAR installer)

Thanks,
Greg