Re: Questions about PEAR & Composer

> So, there was the channel server problem. If you really wanted,
> you could setup a channel (I did), but it was non-trivial until
> 2009/2011 with SCS and Pirum.
>
> Creating a package.xml file is, compared to composer's json config
> file, not trivial. It can be generated via a CLI tool, but it's not
> trivial.

To add to this, we saw a dramatic uptake of people hosting their own
channels once we opened up the installer -
http://pear.php.net/channels/ lists a fair number, most powered by
pirium.
Next, the advent of github removed a significant amount of friction
for "get some code from a repository", and "look at it on the web".
As composer deals with git based installation of packages by design,
it went from "install some software" to "can you use github" as the
barrier to entry.

The other things PEAR offered - issue logging, hosting of code,
collaboration - have had better alternatives come along as well.


Another advantage of composer over PEAR is the local installation of
packages - it took us until pyrus to work out the utility of this for
multiple project environments, and it does make quite a lot of sense
to have a mix of system wide + local.


All of that said, I think we're fairly proud to have built and
maintained a huge number of high quality packages and a distribution
system that is still quite workable ten years in - offering solutions
from highly used (DB/MDB2/etc) to niche (Validate_ES).

You may be interested in http://www.ohloh.net/p/pear ; which does help
explain the changing project; and you can see a few spinoffs (ie:
PHPUnit started in PEAR, PHP_CodeSniffer, PHPDocumentor, etc).

-- 
PEAR General Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php