Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95602
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
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>
 <29848e09-2728-6960-4128-61d4c55d949f@lsces.co.uk>
Message-ID: <b1895f4c-c0aa-5566-0e27-e6de41b80df2@gmail.com>
Date: Sat, 3 Sep 2016 16:43:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <29848e09-2728-6960-4128-61d4c55d949f@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
 composer/pickle
From: rowan.collins@gmail.com (Rowan Collins)

On 03/09/2016 15:56, Lester Caine wrote:
> On 03/09/16 11:20, Rowan Collins wrote:
>> Interesting, can you give any details of these problems?
> https://sourceforge.net/p/tikiwiki/mailman/message/35331374/

Right, so their problem was not with Composer itself, but with Satis, 
which is a tool for publishing or mirroring your own packages, like 
running your own PEAR channel. They wanted to update it for some reason, 
but couldn't because the server had a really old version of PHP, because 
it was running a really old version of Ubuntu. Elsewhere in the thread, 
they have problems downloading a particular version of a package from 
SourceForge. None of this sounds like something that PEAR, or any other 
alternative to Composer, would help with.


>> 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?

I'm not sure what you mean by that. Composer itself is distributed as a 
single PHAR file, and is governed almost entirely by the composer.json 
in your project, and pretty much everything can be different in every 
project. It's an awful lot easier to have multiple setups of that than 
PEAR, which is absolutely designed to manage central system-wide packages.


>
>> 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.

Right, I remember switching to using an autoloader (long long before 
composer existed), and what a relief it was not to have to manage great 
lists of require_once everywhere any more. :) I think the only thing we 
had to fix was some class names being used as lower-case, when the 
filenames that needed including were camel-case. The simplest migration 
that occurs to me is "if ( file_exists('vendor/autoload.php') ) { 
require_once 'vendor/autoload.php'; } else { /* require all the 
individual dependencies as before */ }".


>> 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.

OK, so short story: you're not invoking pear directly anyway, so Davey's 
proposal to remove it won't actually affect you at all.


> 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?

That's pretty much what Satis is for, as mentioned above. Or, if you're 
willing to pay, Toran Proxy, which is how Jordi gets the money to 
improve Composer.

Regards,

-- 
Rowan Collins
[IMSoP]