> On 5 Sep 2016, at 11:19, Stanislav Malyshev <smalys...@gmail.com> wrote:
> 
> Hi!
> 
>> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
> 
> What would be achieved by this? I'm not sure about status of PEAR -
> frankly, didn't touch it for a long time - but if composer replaces most
> of it, it may be ok to remove by-default install of pear tools. Though
> I'm really not sure what "deprecating" means and what it's going to
> achieve.
> 
> Pickle main README says:
> 
> Pickle is a new PHP extension installer. It is based on Composer and the
> plan is to get Composer to fully support it.
> 
> How is that plan going? I see the pull req it refers to still open,
> which means it is still not complete. Should it be completed before we
> recommend it as an only solution?
> 
>> in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
>> in their place.
> 
> Add in which meaning? Distribute composer package with PHP source?
> Wouldn't that add maintenance load to keep it up-to-date?
> 
> If that means get some way to d/l newest stable composer, e.g. when
> installing php, that probably would be a great idea. Does not require
> removing stuff though.
> 
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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`.

Unbundling from PHP itself then makes perfect sense to me - it’s effectively 
mirroring how PHP is actually distributed for a great number of environments 
already.

However, I find the concept of then adding in Composer/Pickle to be a very odd 
choice, and a poor one “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.

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.




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

Reply via email to