Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95630
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.67 as permitted sender)
To: Stephen Reay <php-lists@koalephant.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <0b264e3e-ac31-35b3-083c-27adbb4ccd5e@gmail.com>
 <3708EDBC-659C-4928-92F8-9E46E4A733EB@koalephant.com>
Message-ID: <09f94026-200f-f76d-64a0-e5ee571bbdc9@gmail.com>
Date: Sun, 4 Sep 2016 22:45:51 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <3708EDBC-659C-4928-92F8-9E46E4A733EB@koalephant.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
 composer/pickle
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I think there is value in reducing the number of ‘bundled’ things,
> particularly given that Debian (and thus Ubuntu), Centos and OS X all
> distribute PEAR/PECL as a separate package. On the Linux distro's
> it’s a separate (but possibly “recommended” by php-cli etc) package.
> On OSX there is `/usr/lib/install-pear-nozlib.phar`.

Don't see how it matters what distros do. They certainly build with
non-default options and can re-combine stuff as they want. If you use a
distro it doesn't matter to you how PHP build behaves since you never
interact with it.

> However, I find the concept of then adding in Composer/Pickle to be a
> very odd choice, and a poor one “politically”.

What you mean here? Why is it odd, given the popularity of composer,
which is I think an established fact? Of course, not everybody uses it
everywhere - as each other tool, it is useful for soem specific scenarios.
And what you mean by "politically"?

> As someone else said, bundling composer sounds like an official
> endorsement of PHP-FIG, which I suspect a number of people would have
> issues with.

No it doesn't. What it has to do with PHP-FIG at all? You can use
composer and create composer packages without ever hearing of PHP-FIG,
ever interacting with it or ever needing to. In fact, I don't think FIG
is ever mentioned on the composer site, except when referencing
documents like PSR-0.

I almost no idea what "issues" with PHP-FIG are, but whatever they are,
they are completely irrelevant to the question of whether composer is a
useful tool. IMO, it is, but if people think it is not, we could have a
vote and see.

> On a purely technical level - it makes little sense. As demonstrated
> above, a decent number of environments are not going to ship it as an
> included tool anyway.

Well, yes, of course - I thought that the whole question is that we
should *start* providing it as an option when building PHP, of course we
would not cover environments which don't do it.
-- 
Stas Malyshev
smalyshev@gmail.com