Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95736
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2b8cf7e9-3c66-5c2f-e962-22ad18992aa9@lsces.co.uk>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com> <A8.67.32927.27DDBC75@pb1.pair.com>
 <CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com>
 <C9.2F.45301.38D6EC75@pb1.pair.com> <CAH-PCH5qHdYen33Q_s7kTKM_8qK71v8Ky6kT4fzuRfAwfX06BQ@mail.gmail.com>
 <A7.D5.18051.896CFC75@pb1.pair.com> <CAH-PCH568TPsztkWT553QVQy7jsp1tcqT5w+OT1PoCDt-PbUOg@mail.gmail.com>
 <780c8f3d-bc26-37ff-893d-54be8d438c73@lsces.co.uk> <7ecffe19-f7be-7b51-f952-013812851c2c@gmail.com>
 <2b8cf7e9-3c66-5c2f-e962-22ad18992aa9@lsces.co.uk>
Date: Wed, 7 Sep 2016 18:02:39 +0700
Message-ID: <CAEZPtU70WpbqZZbrw0kxo56re3nLyx6oNX7-ZFSS5LBLkR1WGA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Sep 7, 2016 at 5:51 PM, Lester Caine <lester@lsces.co.uk> wrote:
> On 07/09/16 10:58, Rowan Collins wrote:

> People who already know composer, as perhaps it's all they have ever
> used, are at an advantage. I've tried a couple of times to pick up a
> library that NOW has a composer option, Smarty is a case in point, but
> IT'S use of composer forces changes to the style of working that are
> then at odds with the rest of the framework. Yes over a few years I can
> probably migrate, but this change is adding yet another layer of options
> without any regard to interoperability. I can't apply a simple set of
> rules and switch style as everybody else has their own style of using
> composer? :(

One point, pickle does not need composer to run.

pickle install  memcache will install the memcache extension (windows
binaries, from pecl.php.net, etc) straight away.

The composer integration allows to add extension dependencies and
install them in one go using a composer install (or update).

Also I have to state my opinion on this RFC. I am fine with any
outcome. It would be nice to have for the extensions install
especially as pecl does not support binaries nor VCS or any non
pecl.php.net srcs (but downloaded.tgz).Both pickle and composer won't
be more or less successful if they are or not part of the PHP
releases.

Also both pickle and composer are  tools that can be used with PHP,
HHVM or future compatible php implementations. They are not part of
the php.net projects and will most likely never be. I also do not
consider pecl.php.net as the main place where users can find
extensions but github and in some extends bitbuckets. This is why I
created pickle in the 1st place, to be able to do pickle install <some
repo>/tag/whatever. The upcoming pickle packagist will simply the
packagist.org pendant for PHP/HHVM/etc extensions, without any kind of
releases being available but using the respective services.
Install/Update can then either use the provided archives (they all
provide archives) or install/update straight from git/svn or even cvs
if some of us still have that internally.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org