Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95596
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <23ef1cf8-b81e-661d-fdbe-3a4a19713652@lsces.co.uk>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com> <23ef1cf8-b81e-661d-fdbe-3a4a19713652@lsces.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sat, 03 Sep 2016 11:20:18 +0100
To: PHP internals <internals@lists.php.net>
Message-ID: <03541CD8-0001-4CB7-A8C6-9B931C3C44EE@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: rowan.collins@gmail.com (Rowan Collins)

On 3 September 2016 09:18:48 BST, Lester Caine <lester@lsces.co.uk> wrote:
>Is Composer really all there is?
>I'm looking at the problems projects like tiki have with trying to keep
>composer working in an active project, and other projects have just as
>many bug reports of composer having failed again! Keeping the right
>combination of versions of third party libraries may be what it is
>intended to do, but it does not seem to achieve it.

Interesting, can you give any details of these problems? I've always found composer to do its job very well indeed, and have heard nothing but good things about it. I did a quick search for "tiki composer" and found a page with lots of teething problems from 3 years ago, but I suspect many of those are long since fixed. There's some interesting questions around how to use it for optional plugins, which I hadn't thought about before, but PEAR doesn't do anything to help there either, so not really relevant to this discussion.


> warnings about "You are running composer with xdebug enabled. This
>has a major impact on runtime performance."

So you don't like that the tool defaults to giving you a warning, which can be suppressed, to explain why it might seem slow, due to a debugging tool documented as not being suitable for production because it may have a performance impact? I imagine PEAR runs slower as well, it just doesn't default to telling you so.


> Trying to set up an
>environment where composer only exists for PHP7 so it does not affect
>the legacy systems seems equally problematic.

Do you mean having a single codebase that can be installed with or without composer? Mostly that's just a case of creating alternative autoloader / bootstrap files, since all the code knows about composer at runtime is "require 'vendor/autoload.php';"


> And Packagist has some
>many cross competing packages that it does not make providing a set of
>'supported' php libraries at all feasible?

There is some truth in this, pear.php.net was a curated package library, whereas packagist.org is an open publishing platform. The problem is that for something to be curated somebody has to spend time curating; mostly, the people doing that right now are the big frameworks like Symfony, although there are a few projects like PHP League. The idea behind PHP-FIG is also relevant: rather than PEAR only allowing packages that follow a certain style, users can see on an open market which packages advertise their compatibility.


>If composer is to replace PEAR then it needs to be properly supported
>INSIDE PHP as PEAR is and give the sort of support that PEAR currently
>provides to new users. 

What kind of support are we talking about here? My experience of PEAR is "pear install foo" and in composer that would be "composer require somebody/foo", so I'm interested which scenarios you think need extra work. 

Regards,

-- 
Rowan Collins
[IMSoP]