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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to