2016. szept. 5. 17:32 ezt írta ("Michael Morris" <tendo...@gmail.com>):
>
> 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
> >
For the record pear support local install and composer also provides global
installmethods but you are right that they use the opposite by default.
