How would you improve PEAR?

You might have heard that I’m a member of the PEAR group now. Because of this I’ve been spending a lot of time thinking about what I’d like to see changed in PEAR to make it a better project. I’m slowly building up a list of ideas and at some point I’ll share it, but today I’d like to get some feedback from everyone who reads this blog.

If you were a member of the PEAR group what would you change about PEAR. Please keep in mind were not an all powerful body (Read the constitution for details), but we do have the ability to set policy, and like in any open source project we can make changes through our direct actions.

Thanks in advance for your comments.

25 thoughts on “How would you improve PEAR?”

  1. I’d make a clear distinction between Pear code that ran on PHP4 and code that was written for and would run without errors and warnings on PHP5.

  2. Was Greg not running?

    As for suggestions to PEAR… I’d love to see an easy out-of-box way for bundling PEAR modules into apps. PEAR has never been friendly for shared-hosting users who don’t have the ability to update and maintain a PEAR installation.

    It’d also be nice if PEAR saw a light-weight DB library – the bulk of DB and MDB have always detracted me from using it.

    Lastly… the cross dependencies of some libraries are so excessive its discouraging. I’d hate to set a limit to dependencies, but when I go to use a library that needs 6+ other components to run a menial task we’ve reached the point of over kill.

    Oh one more thing… 🙂 It wouldn’t kill PEAR to allow applications into the mix. I once read Greg talk about that as a limitation of PEAR and am inclined to agree with him. There’s no reason some other excellent apps couldn’t be available via PEAR.

    Just thoughts, probably not even worth $0.02.

    Congrats btw.


  3. oh PLZ PLZ PLZ let pear’s libraries can be used in projects without PEAR. That’s like the only reason I don’t like PEAR stuff…
    also, I would like to have less PEAR projects… all those template project seems like doing the same job… why keep them all there?

  4. I’m still a novice in PHP and maybe therefore I’ve a rather strange idea in your eyes:
    Provide a place not only for code, but also for best practices. There are common problems for almost every webapp. Maybe I don’t like to use the pear package, because it’s not exactly, what I need. But it would be great to have a wiki, where the pros and cons of different strategies are presented.
    Or the arguments regarding __autoload for example. So they don’t need to be repeated in every list. You can simply point on the pear wiki to have all arguments listed. (Or add you own, if your’s not listed yet.)
    There was also an idea in the phpdb list of Lukas, to have a site listing and comparing all the different database abstraction libraries. Such things would be great to have in a central place. What are the pros and cons of phpDocumentor vs. Doxygen? What functionality can I find in different PHP Frameworks?

  5. I agree with the above. I’ve stayed away from the DB library’s because I only need to support 1 (MySQL). Breaking out the classes into lightweight packages is what the community needs.

    Packaging and maintaining is another issue why I haven’t used PEAR much. I generally end up having to put them in directories and change locations in shared environments (which ends up causing problems with syncing local versions).

    I hope this helps PEAR take a step forward. I think the adoption rate could skyrocket as usability does.

  6. Pingback: » Joshua Eichorn’s Blog: How would you improve PEAR?

  7. Personally I find cvs/svn more efficient for keeping applications up to date. But… it is an application repository so maybe it makes sense.

  8. Josh, we’ve had this discussion in private, but here it is for everyone else.

    The move to PHP 5 is a huge step forward. I would like to see it adopt a *nix philosophy where instead of having meta packages that contain a host of functionality, it provides very specific functionality so you can pick and choose what you would like to use without having to manually rip it out of a package.

    That said, I would like to see more meta packages. It was proposed on pear-dev last night that my recent PHP_Callback package should be part of a larger PHP_Util package. I think a PHP_Util package is a great idea, but only as a package that has only dependencies so you could use it to install a collection of packages that provide similar functionality.

    A unified method for building packages would be nice. (i.e., a default phing, ant, etc., script) I’m always for moving to SVN as well 🙂

    Providing simple applications would also be a good way to showcase PEAR usage through example. I wouldn’t get carried away, but having a simple gallery, bookmark app, task list, and maybe even a simple blog would definitely help provide new developers a jumping off point for using PEAR.

  9. One additional area. If civility is going to be maintained, I would recommend coming up with a formal way to address individuals who refuse to be civil. I don’t have to be a public flogging and should happen in private, but I think that would be a great step toward keep things above “you’re an idiot” and “this is useless”.

  10. How about user ratings for individual packages? Or even official “DEPRECATED” and “RECOMMENDED” tags voted on by PEAR for individual packages. Deprecated packages could be moved to an alternate channel even… This would help clear up some of the confusion I think people sometimes experience. Search for “template” on the PEAR site, for example, and you find 5 packages. Sigma, PHPLIB and IT are all ports of the old phplib template library and really shouldn’t be used for modern development in my opinion. They could all be marked deprecated (or pick the most maintained one). XIPE is not maintained and the last release was in 2003. Wouldn’t it make sense to have a “RECOMMENDED” tag by Flexy?

    If PEAR doesn’t want to be selecting packages than user ratings would doubtless accomplish the same thing. I do appreciate the message on the docs page for DB which directs you to MDB2 – it helps casual users make decisions about which packages to use in development.

  11. I’d also vote for more lightweight packages. I think most developers would agree when I say that re-inventing the wheel of anything is a very bad idea for various reasons. That however is often only remaining option in a cases where you just look for one particular solution and don’t want a whole bunch of dependent classes.

    So maybe it would be clever to provide some sort of subpackages of packages that tend to grow very fast simply because the corresponding developers have a lot of ideas of features that could be added.

  12. I have two sets of suggestions

    1. Political and Social Issues
    a) PEAR needs to be more professional – the things I read in pepr and see in the mailing lists appall me, it’s an emotional nasty mess. Attacking other people’s methods of code (more OO, more procedural, blah blah blah) is useless and makes you look like a pack of children. If people can’t think before they speak maybe there needs to be a way to have public sanctions on those who can’t keep their mouth shut. PEAR already has an image problem.

    b) Embrace new developers – instead of attacking every new thing that comes along, PEAR should be embracing and mentoring newcomers. I’ve never seen a more antagonistic approach to new developers.

    c) Mentoring – the best way to get new developers (like Greg) is to create them from your pool of enthusiastic newbies. Create specific “goals” or “projects” with a mentor (a la google summer of code only ongoing) – in no time that newbie will be an expert.

    d) Image Fixing – PEAR is losing ground. PHP4 is dead. PEAR is a closed group of antagonistic developers locking into PHP4 coding – whether any of these statements is actually true or not is irrelevant – on the web people want to jump on the bandwagon. PEAR needs to fix it’s image problem if it wants to stay relevant.

    2. Code issues
    a) A good fix for all the infighting over “should this be in PEAR” might be to branch out PEAR. You have channel support that is great – why not create a PEAR main channel for the “officially sanctioned” core code, and a libs channel for all kinds of misc packages, they may only be of use to some people but why keep good code out? (and good does not necessarily mean useful to all), also this would be a good place to let in competeing packages. If they get stable and popular enough maybe they might be taking over that core sopt. Finally and applications channel – PEAR needs applications.

    b) PEAR needs a new PHP5 core – and tutorials for new developers. Nothing teaches PEAR cs, how to deal with exceptions and errors, better than a few lines of code. My core would ideally have,
    1) An error/exception base class (with clear rules on how it must be used)
    2) A thin db abstraction layer (I’d say pdo based with some added stuff like limit, quote for drivers that don’t support it, escaping identifiers, and building querys – ANYTHING ELSE like recordset handling, nested transactions, activerecord, all that jazz, should be built on top and not forced into the stuff.
    3) An MVC package that would make app creation quick, and not seperate packages for each either, but a nice integrated option with tutorials
    4) A templating interface – despite all the crap about templates, in the end they work the same, assign template variables, tell it the template to use, display it. Then drivers for different templates could be created. (PHP streams are very powerful and can hide everything from caching and compiling any other fancy crap if things are set up right)
    5) Security Features – validation, filtering, and session/cookie security that uses encryption and such

    c) A channel registration and search engine. So I could do pear search database mysql and every package with database and mysql would pop up, cross channel

    d) limit dependencies – I’d say three would be an absolute limit, plus an error/exception dependency

    e) PEAR that does a drag – n – drop – pear is not a framework, people don’t use pear like a framework, so why does the installer treat them like a framework? Why can’t it just copy the files into a location, fix any needed strings and let it run? It shouldn’t be touching any env variables or php.ini settings. It should run regardless of include_path settings. I haven’t played too much with the installer but I shouldn’t have to install a local pear to use one package, and I shouldn’t have to hack the classes to get includes working

    f) Includes – a standard mechanism for __autoload and includes should be put in place because the current one sucks. using spl_autoload_register you could push an autoload on the stack and not even touch other people’s stuff. Using nifty detection you could make autoload only be called initially and load a list of classes, since there is a performance hit for using it

  13. oh, and before I forget again – PEAR is not very windows friendly (pecl as well) – pecl install blah on windows should yank the right dll down from pecl4win, alter the php.ini, and go 😉

  14. For those who are wondering, most of the suggestions here are in fact already implemented or in the planning stages. There is really only one that is not:

    1) SVN. CVS is here to stay, as we are dependent on HOWEVER, someone willing to donate dedicated hardware would pique our interest in having optional subversion hosting.

    Things that are implemented already:

    1) pear installer is capable of modifying php.ini, but it does require a binary package to be created with the dll.
    2) PEAR_Exception is the error/exception base class.
    3) Mentoring. The new constitution ( requires mentoring of new developers.
    4) package tags. This was recently implemented, in anticipation of the new collectives, and other useful purposes.
    5) deprecated/unmaintained packages have been supported for a while now (see for an example)
    6) lightweight packages. See for an example. All of the database drivers are decoupled into subpackages. Structures_DataGrid is the most complex example of this de-coupling. The technical capability was not present before PEAR version 1.4.9 to handle this properly, and so most packages have not yet implemented this functionality.

    The social issues are a real problem. I plan to make this my primary purpose as the PEAR president (this is why I’m not in the PEAR Group Stan, I ran for the president of the whole thingy), separate from my work as a developer. We’ll see how it goes, but I see a strong momentum shift in the makings here, which has been my dream for several years. It’s exciting to see it moving forward so dramatically. I hope that more developers who see the potential and the things that can happen will join, it is only through the force of the will of people who believe in things like civility that PEAR will shift its culture to one that encourages innovation as well as stability.

    One thing you can currently depend upon in PEAR that will never be changing is that packages marked stable will always work in a similar way, such that you won’t find applications based on them suddenly breaking on upgrade. Innovation can always be provided without destroying the work of your users. Stay tuned for details of how things will be changing

  15. Greg,
    Excellent! I didn’t see your name anywhere on the list and was concerned that PEAR was missing out on a valuable resource – I only keep up to date on PEAR-appenings from time to time.

    Thank you for pointing out the implementation of some of these suggestions – I think the general feel of some of the posters here is that these are great moves… we all just hope they are contagious to other parts of the project. I’m hopeful for the direction PEAR is headed in.

    On a slightly side note, noticing the release of HTML_AJAX 0.5.1 today – and thinking to myself that a bridge between HTML_AJAX, it’s internal JS library and jQuery or even Prototype would be handy. I’d love to see PEAR in general adopt some bridge-type packages for interacting with already establishing open source libraries. HTML_AJAX in particular has the potential to be driver-based and allow PHP developers to keep up with their existent JS practices. How cool would that be?

    Anyhow, that’s my $0.02 – but don’t take it to the bank.

    – Stan

  16. Pingback: » Greg Beaver’s Blog: Is anything working in PEAR?

  17. Pingback: Joshua Eichorn's Blog » Blog Archive » Thanks for your thoughts on improving PEAR

  18. * read the patch ppl send. We have found many bugs, send the patch, never see the updated, and read that someone else has, found many bugs, send the patch and never see the update.

    * pear upgrade-all –alldeps

    * pear install package –target

    * E_STRICT pls, force all packages to be upgraded for PHP5

    * let other projects be hosted by the pear channel in their own namespace, like
    pear install Solar_SolarFramework
    pear install Zend_Framework

  19. Asking developers who cannot devote much time to step back and let others do the work.
    It is no use for nobody when the estimated time of getting a usable package is many years in the future. If somebody does not have the time, he shouldn’t attempt to create new demanding packages.
    There have to be regulations of how long a package can stay in alpha and beta state, before the project lead is vacant.

  20. Using just part of Pear code would be nice. Of course with giving a reference to the source. There are many times I’d just like to use one function and not the whole library.


Comments are closed.