Please be cautious - composer isn't a complete replacement for PEAR because it doesn't behave the same way. For the most part this is a good thing, but please consider the following.
On not one but two occasions I was tasked after being hired with upgrading PHP versions from 4.x to 5.3. In both cases the programmers on staff who had inherited the balls of mud in question swore up and down it couldn't be done - on both occasions it was because they weren't copying the PEAR libraries over to the new PHP install. PEAR is a global installer, and unfortunately I imagine there are a lot of legacy sites that have been inherited by inexperienced coders who don''t know what it is (cause it is used so rarely these days) that have pear libs in use. If they need to build a new version of PHP they are at a complete loss unless they know what they are doing because, more often than not, the requirement of pear libraries in PHP apps that use them go undocumented. Composer is superior for several reasons, but one of them is that it doesn't share this flaw. The requirements of a composer project are listed explicitly in the composer.json file - often down to the version # of the code in question. While abandoning PEAR seems sensible, abandoning its plugins, not so much. To say nothing of PECL extensions which are, if I recall correctly, written in C++ and extend the PHP runtime directly. Also, as Tony Marston pointed out, there are CPanel systems that allow the pear libraries to be managed from a web gui. Given time I'm sure the folks at cpanel will build new interfaces for new systems if it's possible. Composer however doesn't really allow for this since the dependencies belong to the PHP application, not the server. Does it make sense for any new system to allow for server wide installing? Composer does have global requiring, but it's usually for support tools meant for use at the command line like PHP Unit. Despite the misgivings above, I do support the aims of this RFC and hope they are considered going forward. On Fri, Sep 2, 2016 at 3:32 PM, Davey Shafik <m...@daveyshafik.com> wrote: > Hi internals, > > 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 > > I highly recommend reading the twitter poll and accompanying thread at > https://twitter.com/dshafik/status/756337267547832320 > > I believe that pickle solves the issues with regards to pecl, and have run > the idea passed Jordi and Pierre. Both are fine with this RFC. :) > > I understand that adding in composer/pickle is just setting us up for > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so > I've proposed the voting reflect that some people will just want to > deprecate/remove pear/pecl and not replace them at all. > > I'm also proposing voting choices around the optional/default introduction > of composer/pickle. > > - Davey >
