Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95599
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
To: internals@lists.php.net
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <23ef1cf8-b81e-661d-fdbe-3a4a19713652@lsces.co.uk>
 <03541CD8-0001-4CB7-A8C6-9B931C3C44EE@gmail.com>
Message-ID: <29848e09-2728-6960-4128-61d4c55d949f@lsces.co.uk>
Date: Sat, 3 Sep 2016 15:56:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <03541CD8-0001-4CB7-A8C6-9B931C3C44EE@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
 composer/pickle
From: lester@lsces.co.uk (Lester Caine)

On 03/09/16 11:20, Rowan Collins wrote:
> 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.

https://sourceforge.net/p/tikiwiki/mailman/message/35331374/

>> 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.

But being able to set up an environment where it is easy to switch tools
on and off is being complicated by having to manage different 'composer'
setups. Something which I don't think it was actually designed to handle?

>> 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';"

This is perhaps my sticking point. I have a perfectly stable framework
without the need for any 'autoloader', and a folder structure that
works. Reworking the whole framework so that it follows the 'vendor'
rules while still also just working with bog standard require_once in
the right place is where I keep coming unstuck.

>> 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.

I don't think the current PEAR suite will disappear since it does
provide a clean set of tools, and probably at least 80% of legacy
systems still rely on it. I've just been stung by 'mcrypt' not being
available with a couple of the owncloud alternatives I tried. They will
not install on PHP7, and I think I'm going to have to roll back to
PHP5.x to get that working.

>> 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. 

I WAS using SUSE's software management to keep all my production
machines working cleanly. Currently that provides 5.6.9 along with every
pear package I use. composer does not figure at all, but node, pip and
bower all get support. Although I get the impression that a combination
of npm with composer may be the way forward. npm can manage the
development dependencies such as css tools as well as javascript
management, but then do I actually need composer as well? Although I
will ALWAYS prefer supplying the distributed library files I need from a
local server rather than assuming they will remain available from some
third party site, and it's that which I can't do with composer?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk