On 02/09/2016 20:32, Davey Shafik wrote:
I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
in their place.
https://wiki.php.net/rfc/deprecate-pear-include-composer
Hi Davey,
I think this is a sensible idea. It basically accepts the reality that
PEAR is no longer the main place new users of PHP should look for
3rd-party code.
Thinking about the responses so far, I thought it would be useful to
enumerate just what PEAR is, and what is being proposed for removal. It
might even be worth adding a version of this to the RFC, in case it
reaches a wider audience who won't see this discussion.
As I understand it, PEAR is:
A1) A command-line package management tool for installing and updating
packages of PHP code over the Internet.
A2) A curated default "channel" for the package management tool, at
pear.php.net
A3) The coding style guidelines for publishing on that channel
A4) An ecosystem of packages built to those guidelines
While PECL is:
B1) A related command-line tool for managing extensions to PHP itself.
B2) A default channel for the extension management tool, at pecl.php.net
The command-line tools (A1 and B1 above) are currently distributed with
PHP by default, and this is what we are looking to deprecate. Composer
is the common choice to fill the role of A1, and "pickle" is being
proposed as the official replacement for B1. Everything else will still
be there, including the ability to download the tools, probably through
your OS or stack's package management system.
As to the rest, a few rambling thoughts:
- There is no single replacement for pear.php.net. packagist.org
partially fulfils job A2, but it is a marketplace, not a curated
channel, and it doesn't do anything to standardise style (A3) or
interoperability (A4). PHP-FIG is one attempt to fill that
standardisation; it's entirely voluntary, and entirely separate from
php.net, but it's not like anyone was ever forced to publish on
pear.php.net.
- pear.php.net is technically only one "channel" compatible with the
tool, but I'm not sure how many others are out there in practice. As a
random example, I know that Swift Mailer used to maintain a PEAR
channel, but checking back it is now officially unsupported:
http://pear.swiftmailer.org/
- On the flip side, many of the packages that are published on
pear.php.net are also available on packagist.org for installation with
composer, either in this list https://packagist.org/packages/pear/ or in
unofficial forks.
- The PEAR coding style would probably be considered "out of date" by a
lot of PHP devs. That's partly a matter of fashion, but also a natural
consequence of it predating certain language features - autoloading,
namespaces, etc - which people want to take advantage of.
- There is a "PEAR2" consisting of the "pyrus" tool, and pear2.php.net.
It appears to be basically abandoned, although it is still prominently
linked from pear.php.net. I assume pyrus never made into the default
distribution of PHP?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
