Re: Questions about PEAR & Composer

Hello Sequoia,


> 1. Why did PEAR not catch on more widely?  Were technical limitations
> like lack of namespaces a major factor or was it primarily cultural?

PEAR was invented in 2001, namespaces came only with PHP 5.3 in 2009.

You need to differ between the PEAR installer, which composer is
related to, and the PEAR package library. Those are two different
things, even though they have the same name.

The installer - it only got multi-channel support with PEAR 1.4 in
2005. Before, you could only install packages from pear.php.net.

After that, you could host your own channel but seldom anyone did that
because there was no simple channel server software.
The Chiara PEAR server appeared in 2006 and was the first of its kind,
but needed a database and many dependencies.
SimpleChannelServer came in 2007 and was PHP 5.3 only - which at the
time was not under construction - so it could only be used from 2009 by
normal people.
Pirum then came in 2011 and was the only one to gain widely attraction.

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.

----

The package library:
I think the problem was that many of its packages were written in PHP4
times, and were not updated to be PHP5 only (because of PEAR's very
strict backwards compatibility rules; it requires to register a new
package). The PHP4 code worked mostly, so the maintainers did not see a
reason to take the effort to create new packages for PHP5 only.

Also, many package maintainers left at the time PHP5 (and 5.1/5.2)
came, not contributing anymore.
PEAR as a project failed to gain new developers, so today there are
only a few active ones left.


> 2. What were some of PEAR's most notable successes?
I'd say the PEAR installer itself. It's still used on thousands of
servers to manage PHP dependencies.

Have a look at http://pear.php.net/package-stats.php

The XML-RPC package is used most widely, followed by the PEAR
dependencies, then the DB and HTTP_Request package. Net_URL2 and MDB2
are used very widely, too.

Also, PEAR is used to install PECL extensions from http://pecl.php.net/.


> 3. What's a good example of a popular project that relies heavily on
> PEAR today (or in the past)?
The status.net software that powers http://identi.ca/ relies on
quite a number of PEAR packages. TYPO3 (CMS) uses with some PEAR
packages internally.

I don't have more in my head right now.


> 4. How is PEAR different than Composer/Packagist?
You need a channel server with a structure of XML files and a
package.xml file for your package, while composer can work directly off
git repositories containing a small composer.json file.


> 5. What does the future hold for PEAR & what is its role if Composer
> continues on its trajectory towards being the de facto dependency
> management tool in PHP (and package repo with Packagist)?

For now, the PEAR installer is the only one that's able to install PHP
extensions, so it'll stay around until composer can also do that or
something better is invented.

Also, there is Pyrus, the PHP5.3+ PEAR installer -
http://pear2.php.net/PEAR2_Pyrus - it was meant to bring the PEAR
installer to PHP5, but did not gain traction.

Apart from that, I don't know what the future will hold. Composer is
being developed actively, that's for sure.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-= Geeking around in the name of science since 1982 =-

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