http://phplens.com/lens/adodb/#1
The PEAR one takes almost twice the time of all other wrappers, with the exception of M'base.
I hate it when my prejudices are confirmed. Makes my life boring. ..
Come to the PEAR-fest
Moderator: General Moderators
In some of the benchmarks that I've done, PEAR DB performs better. I would say they are fairly equivalent, just optimized for different things. adodb has an optimized inner loop and the test above shows it off. If you look at the second benchmark on that link, you will see that PEAR beats adodb for a more realistic example, but only when you do not have an opcode cache. Do you have 5*200 82 record SQL queries per request in your app? Benchmarking is the devils game.patrikG wrote:BTW, I've just come across some benchmarks comparing different DB-wrappers:
http://phplens.com/lens/adodb/#1
The PEAR one takes almost twice the time of all other wrappers, with the exception of M'base.
There is some really nice stuff in PEAR. It seems, though that many people look at the base PEAR.php and form a negative opinion (with good reason.)
There is a lot of questionable design in PEAR.php. First, since PHP is dynamically typed, a base object class isn't necessary. Java needs such a thing, PHP doesn't.
In fact, inheritance is a brittle. a lot of the base class seems to be devoted to simulating features that the PHP object model didn't have (exceptions, destructors, class variables, etc.) Unfortunately many of these things cannot be simulated adequately without language support. Fortunately, PHP has added language support for these things. Unfortunately, now PEAR is stuck with useless code for backward compatibility at the very center of their library.
Another problem is that PEAR can't decide what it wants to be. Is it a library? Is it an application framework? Is it a loose collection of libraries? If you look at their five template implementations, you might think its a collection of libraries. Quickform implements validation, and so does a validation module. On the other hand, some attempt is made to have a cohesive whole. unfortunately, this seems to center around the base class and error handling.
Now, error reporting in a library is essential. You must have some way of reporting errors. However, error handling is generally NOT the job of a library. It is the job of the top level application. Especially because of PHP < 5 error handling scheme. With exceptions, you can handle errors at multiple levels. With error handers, you can only handle them at the top level. This is what I think gives people so many problems. PEAR should never have gotten into the business of error handling. The problem is that they have done so by welding it on to their required base class in a heavy handed way.
Another issue is deployment. There are few PEAR modules that you can just download and use. You have to go through an entire PEAR installation process. Why? mostly because they inherit from PEAR for some feature that they barely use.
PEAR.php must die! long live PEAR.
There is a lot of questionable design in PEAR.php. First, since PHP is dynamically typed, a base object class isn't necessary. Java needs such a thing, PHP doesn't.
In fact, inheritance is a brittle. a lot of the base class seems to be devoted to simulating features that the PHP object model didn't have (exceptions, destructors, class variables, etc.) Unfortunately many of these things cannot be simulated adequately without language support. Fortunately, PHP has added language support for these things. Unfortunately, now PEAR is stuck with useless code for backward compatibility at the very center of their library.
Another problem is that PEAR can't decide what it wants to be. Is it a library? Is it an application framework? Is it a loose collection of libraries? If you look at their five template implementations, you might think its a collection of libraries. Quickform implements validation, and so does a validation module. On the other hand, some attempt is made to have a cohesive whole. unfortunately, this seems to center around the base class and error handling.
Now, error reporting in a library is essential. You must have some way of reporting errors. However, error handling is generally NOT the job of a library. It is the job of the top level application. Especially because of PHP < 5 error handling scheme. With exceptions, you can handle errors at multiple levels. With error handers, you can only handle them at the top level. This is what I think gives people so many problems. PEAR should never have gotten into the business of error handling. The problem is that they have done so by welding it on to their required base class in a heavy handed way.
Another issue is deployment. There are few PEAR modules that you can just download and use. You have to go through an entire PEAR installation process. Why? mostly because they inherit from PEAR for some feature that they barely use.
PEAR.php must die! long live PEAR.
Re: Come to the PEAR-fest
Hi...
I don't like to slag other's hard work, but as nothing ever seems to change I think it is really time to come off of the fence. So I have big time. Ready with the flak jackets...incoming...
I'll make a distinction between PEAR the common code and culture, and the actual classes in there. The contributed packeges are pretty much what you would expect. Some great, some good, some bad. If you have a gripe about a particular package, then you contact the author. I find that the quality is similar to CPAN (maybe only a little lower). Unfortunately there is real rot within PEAR culture and I don't see it being sorted out any time soon.
The fundamental problem is that it doesn't really know what it is. If it was a public package repository (like CPAN) then it would at least have potential. The trouble is that in the hope of getting reuse they have instituted a dev discussion list in which you have to get 5 votes and duplication of function is not allowed. The result is that the first person to announce does a land grab on a package. It doesn't matter how good a follow up package is, it won't get in. Instead of improving quality by evolution (as in CPAN) we have a stagnant mess in which people recode things in their own classes because they cannot get the one and only PEAR one to work. If thay manage to get a supporting feature in a package for their own work then they are bloating the service class, making it even less reusable. The whole system seems to have been designed to destroy cohesion.
The voting system doesn't help either. I had the dubious task of monitoring pear-dev and it was painful. The other attendees will give the most cursory look at an incoming package. They usually don't understand the objective, find some relatively minor piece of duplication and then reject it. Some excellent work has been rejected by this self appointed club. MDB is a superb package, but had a hell of a job getting because of DB (fortunately it did succeed, not helped by the original author). They are not the same thing, having very different design priorities, but it took years to point this out.
To make matters worse unscrupulous owners can claim that a package actually falls under their own remit and they were going to release something anyway, again causing rejection. This is M$ style preannouncement. I have been a victim of this and I saw two other instances in three months. The only hope is usually to submit a nearby package and sneak something useful in under the banner. I have seen some stuff get in this way, but cannot say which for fear of causing the authors rejection in the future.
PEAR has this idiotic sheme because it also thinks it is a class library. Class libraries are not made this way, they are reworked by small talented groups. Class libraries are achieved by refinement and refactoring. You can only have refactoring with tests and shared ownership. That's when you get reuse and quality. PEAR has neither. In fact ownership is positively encouraged, with people doing articles and conferences based on "their" package.
And then there are the base classes. It's almost as if to justify their existence that they had to come up with a base class. No class hiearchy should be deepened unecessarily. Have they heard of favouring composition over inheritance? Even frameworks rarely require inheritance (Naked objects is the only one I can think of off-hand). PEAR certainly won't be building a framework any time soon. This is way harder than a class library.
This spirit of making unecessary work spread to the broken error handling. Error handling is an architecture decision, not a library one. LIbraries that use PEAR are either forced to wrap the classes to avoid it, or get dragged into the same mire. It is not even any good, inflicting a static method call as well as returning a special object. The worst of both worlds. You don't know what errors are involved just from the interface so it actually manages to obscure and complicate the code rather than cleaning it up. It takes true genius to come up with a more convoluted system for a non-problem.
A solution? Make PEAR a package manager/installer. Also a public repository in charge of namespaces. Insist on complete test coverage and documentation rather than rejecting on grounds of duplication. If a module became unpopular or has too many a bug, record this fact and make it public. Let the library self select. All of this would have the effect of sacking the middle mis-management of PEAR. To be brutal I think this is overdue.
PEAR is distorting the whole of the PHP community. But who is going to fix it?
yours, Marcus
I don't like to slag other's hard work, but as nothing ever seems to change I think it is really time to come off of the fence. So I have big time. Ready with the flak jackets...incoming...
I'll make a distinction between PEAR the common code and culture, and the actual classes in there. The contributed packeges are pretty much what you would expect. Some great, some good, some bad. If you have a gripe about a particular package, then you contact the author. I find that the quality is similar to CPAN (maybe only a little lower). Unfortunately there is real rot within PEAR culture and I don't see it being sorted out any time soon.
The fundamental problem is that it doesn't really know what it is. If it was a public package repository (like CPAN) then it would at least have potential. The trouble is that in the hope of getting reuse they have instituted a dev discussion list in which you have to get 5 votes and duplication of function is not allowed. The result is that the first person to announce does a land grab on a package. It doesn't matter how good a follow up package is, it won't get in. Instead of improving quality by evolution (as in CPAN) we have a stagnant mess in which people recode things in their own classes because they cannot get the one and only PEAR one to work. If thay manage to get a supporting feature in a package for their own work then they are bloating the service class, making it even less reusable. The whole system seems to have been designed to destroy cohesion.
The voting system doesn't help either. I had the dubious task of monitoring pear-dev and it was painful. The other attendees will give the most cursory look at an incoming package. They usually don't understand the objective, find some relatively minor piece of duplication and then reject it. Some excellent work has been rejected by this self appointed club. MDB is a superb package, but had a hell of a job getting because of DB (fortunately it did succeed, not helped by the original author). They are not the same thing, having very different design priorities, but it took years to point this out.
To make matters worse unscrupulous owners can claim that a package actually falls under their own remit and they were going to release something anyway, again causing rejection. This is M$ style preannouncement. I have been a victim of this and I saw two other instances in three months. The only hope is usually to submit a nearby package and sneak something useful in under the banner. I have seen some stuff get in this way, but cannot say which for fear of causing the authors rejection in the future.
PEAR has this idiotic sheme because it also thinks it is a class library. Class libraries are not made this way, they are reworked by small talented groups. Class libraries are achieved by refinement and refactoring. You can only have refactoring with tests and shared ownership. That's when you get reuse and quality. PEAR has neither. In fact ownership is positively encouraged, with people doing articles and conferences based on "their" package.
And then there are the base classes. It's almost as if to justify their existence that they had to come up with a base class. No class hiearchy should be deepened unecessarily. Have they heard of favouring composition over inheritance? Even frameworks rarely require inheritance (Naked objects is the only one I can think of off-hand). PEAR certainly won't be building a framework any time soon. This is way harder than a class library.
This spirit of making unecessary work spread to the broken error handling. Error handling is an architecture decision, not a library one. LIbraries that use PEAR are either forced to wrap the classes to avoid it, or get dragged into the same mire. It is not even any good, inflicting a static method call as well as returning a special object. The worst of both worlds. You don't know what errors are involved just from the interface so it actually manages to obscure and complicate the code rather than cleaning it up. It takes true genius to come up with a more convoluted system for a non-problem.
A solution? Make PEAR a package manager/installer. Also a public repository in charge of namespaces. Insist on complete test coverage and documentation rather than rejecting on grounds of duplication. If a module became unpopular or has too many a bug, record this fact and make it public. Let the library self select. All of this would have the effect of sacking the middle mis-management of PEAR. To be brutal I think this is overdue.
PEAR is distorting the whole of the PHP community. But who is going to fix it?
yours, Marcus
.It's very thought-provoking to see all these (well argued) gripes against PEAR - including an inside view of the PEAR-ocracy. The main thought provoked is what to do next.
Perhaps a small start would be to create a list of "gold standard" php? If PEAR isn't (or isn't always) the pinnacle of php one might expect it to be, I'd be very interested to hear what you think are some of the best examples of programming in the language. Eclipse, for example, would get a vote here.
A list might serve as a focal point for arguing the case for change, helping to explain what it is that we don't like about PEAR and providing models for best practice. It might also show if it's actually possible to agree about what constitutes quality code in the first place
Are there enough bits and pieces out there to create the nucleus of a new library if PEAR can't be changed?
The library at the heart of php ought to be an example of the very best work being done with the language. That's good for developers, good for learners who can be pointed towards some quality example code and good for the reputation of php as a serious option.
Perhaps a small start would be to create a list of "gold standard" php? If PEAR isn't (or isn't always) the pinnacle of php one might expect it to be, I'd be very interested to hear what you think are some of the best examples of programming in the language. Eclipse, for example, would get a vote here.
A list might serve as a focal point for arguing the case for change, helping to explain what it is that we don't like about PEAR and providing models for best practice. It might also show if it's actually possible to agree about what constitutes quality code in the first place
Are there enough bits and pieces out there to create the nucleus of a new library if PEAR can't be changed?
The library at the heart of php ought to be an example of the very best work being done with the language. That's good for developers, good for learners who can be pointed towards some quality example code and good for the reputation of php as a serious option.
Just a quick one: the more I read about PEAR the more I become aware of a couple of things:
a) PEAR is slowly becoming more mature but is still far from yummy
b) the PEAR developers are, of course, fully aware of the current shortcomings of PEAR.
c) they are trying to change the internal architecture (and everyone who has ever done something like that to an application/development framework knows what hell that must be, especially with such a heterogenous codebase) - are they really?
Now, given all that and seeing where PHP5 is going, i.e. towards a very robust enterprise level language like Java is, it seems very much that PEAR as a library would fit right into that concept.
I don't think a replacement for PEAR is necessary - if one remembers where it's coming from, I start to believe that it's actually making headway - and into a good direction.
All of us developers arguing about the benefits of our template classes, our great database wrapper or this, that and the other are missing one thing: a real code library. Unless that is there, PHP will always be somewhat of a step-child of "proper" programming languages like Java and C (in all it's variants).
And yes, even ASP has the advantage of not forcing everyone to either find an appropriate class on hotscripts.com or phpclasses.org or write their own, but a development framework.
Let's face it: we (and by that I actually mean I) are a bit like the step-mom always moaning that this and the other is not right, while we are actually not seeing that things are really moving ahead.
a) PEAR is slowly becoming more mature but is still far from yummy
b) the PEAR developers are, of course, fully aware of the current shortcomings of PEAR.
c) they are trying to change the internal architecture (and everyone who has ever done something like that to an application/development framework knows what hell that must be, especially with such a heterogenous codebase) - are they really?
Now, given all that and seeing where PHP5 is going, i.e. towards a very robust enterprise level language like Java is, it seems very much that PEAR as a library would fit right into that concept.
I don't think a replacement for PEAR is necessary - if one remembers where it's coming from, I start to believe that it's actually making headway - and into a good direction.
All of us developers arguing about the benefits of our template classes, our great database wrapper or this, that and the other are missing one thing: a real code library. Unless that is there, PHP will always be somewhat of a step-child of "proper" programming languages like Java and C (in all it's variants).
And yes, even ASP has the advantage of not forcing everyone to either find an appropriate class on hotscripts.com or phpclasses.org or write their own, but a development framework.
Let's face it: we (and by that I actually mean I) are a bit like the step-mom always moaning that this and the other is not right, while we are actually not seeing that things are really moving ahead.
I've just come across this very informative article on PEAR. Nice!
PEAR has also started to publish a weekly newsletter:
Issue 1, 25 March 2004 is at
http://www.zend.com/zend/pear/pearweek1.php
Issue 1, 25 March 2004 is at
http://www.zend.com/zend/pear/pearweek1.php
Replacement - no. Alternatives? Yes, absolutely.patrikG wrote: I don't think a replacement for PEAR is necessary - if one remembers where it's coming from, I start to believe that it's actually making headway - and into a good direction.
So lets recap - we have a group (PEAR-dev) that says "this is the best, and this is the only way we will do DB access". Then you, as a programmer, look at that method for doing DB access, and see a BETTER version in adodb. So now you have a choice - you can use adodb, or you can use PEAR-db.patrikG wrote: All of us developers arguing about the benefits of our template classes, our great database wrapper or this, that and the other are missing one thing: a real code library. Unless that is there, PHP will always be somewhat of a step-child of "proper" programming languages like Java and C (in all it's variants).
Code libraries thrive on competition. PEAR-dev has rejected that fundamental advantage. Thats why Perl does SO well - CPAN isnt controlled by a 'ruling class', its survival of the fittest. Time and again, in CPAN, traditionally well-supported classes are replaced by newer, faster, more functional classes. And then those are replaced by the traditional class, which adds said functionality. The process is both fast and useful.
PEAR has no such competition. Once you are the BLANK pear method, you are in for good, and no other BLANK library can compete.
Oh things are moving ahead all right, just not in PEAR generally.patrikG wrote: Let's face it: we (and by that I actually mean I) are a bit like the step-mom always moaning that this and the other is not right, while we are actually not seeing that things are really moving ahead.
Over a year ago, I tried to restructure an app to use PEAR. *HUNDREDS* of admins trying to install my app complained relentlessly about the difficulty of installing PEAR just to get my app working.
Nothing has changed - most webhosting companies don't offer PEAR pre-installed for customers, and as a result, you have to do-it-yourself.
Worse, the license on all PEAR code prevents direct linking with GPL'd code. While the same can be said in reverse (GPL'd code cannot directly link with PHP-licensed code either), for me the issue was stark - the codebase I was working with WAS GPL'd. Once I found out the licenses were incompatible, I had no choice - I couldnt legally use both together.
The movement forward IS happening - there are literally dozens of 'frameworks' of backends for interfacing with everything from databases (adodb), to templating (smarty, etc), and more.
Those frameworks (eclipse, blueshoes, etc) directly provide competition to PEAR. Not only are some of the frameworks smaller, easier to install, and better supported, but they use a license that allows linking to GPL'd code.
I admit to being biased - I am currently working on an extensive 'toolkit' for php developers to utilize ala PEAR.
Competition is key, and PEAR doesnt get that. Never have, never will. Which is why they will lose.
No, you misunderstood me, Roja. I am not arguing for a monopoly, but for a coherent, well documented standard code-base which every PHP-developer can use. Whether there is one DB-wrapper or 10 doesn't matter to me as long as the one I am using works fine and does what I want (oh, PEAR has five different template classes, btw).Roja wrote:So lets recap - we have a group (PEAR-dev) that says "this is the best, and this is the only way we will do DB access". Then you, as a programmer, look at that method for doing DB access, and see a BETTER version in adodb. So now you have a choice - you can use adodb, or you can use PEAR-db.patrikG wrote: All of us developers arguing about the benefits of our template classes, our great database wrapper or this, that and the other are missing one thing: a real code library. Unless that is there, PHP will always be somewhat of a step-child of "proper" programming languages like Java and C (in all it's variants).
Code libraries thrive on competition. PEAR-dev has rejected that fundamental advantage.
PHP is becoming increasingly popular and accepted in commercial circles (e.g. Oracle’s 10G will include PHP on the distro-CDs), PHP5 will have pretty much fully-fledged OO implementation as well as SOAP bundled – in short: PHP is becoming mature.
Because of that, PEAR needs to be what it originally set out to be. In time-critical environments (i.e. the bloody workplace), the benefits are measured in money – anything that makes developing an application easier, makes it cheaper and thus more attractive.
You simply can’t have PEAR be a hotchpotch of classes – some great, some crap. It needs to be a coherent framework. If that can’t be done, it might be worth re-thinking the entire project or using another one.
I am not arguing against other development frameworks, but PEAR was to be PHP’s default framework. That makes it somewhat “first among equals” in terms of status, not in terms of consistent quality. By that I mean, people will first look at what PEAR has to offer. Not finding it there will prompt them either to
a) be not very impressed by or even forget about PHP as a whole
b) walk the extra mile and look at all the other frameworks and classes out there – which is time-consuming.
Personally, I don’t see PEAR being a “us and them” scenario. PEAR is something I would like to see become the way it was supposed to be – so that PHP becomes simpler and people don’t need to constantly re-invent the wheel.Roja wrote:Competition is key, and PEAR doesnt get that. Never have, never will. Which is why they will lose.
Diversity is the greatest strength of the open-source movement, but at the same time it is its great weakness. With every new framework/db-wrapper/template-class you’re adding complexity – which is fine if you’re a seasoned developer who has been around for a while, can assess the quality and purpose of the code etc. If you’re not, however, learning PHP becomes more difficult than it should be.
My point is: make developing in PHP as simple as possible – and PEAR set out to offer that. It needs to live up to that and quickly, if possible.
Hi,
I have briefly looked at some of the comments and I am in a very unique position to shed some light on things.
1) I am a member of the PEAR Group
2) I am also the lead developer of MDB
As such I am very much involved in what goes on in PEAR and I am also someone that came with an alternative to PEAR.
Anyways there is no rule in PEAR thats states that you need to extend PEAR. There is only the rule that you need to use PEAR error handling. This is a distinct difference which means that you dont need to extend PEAR at all.
One thing that alot of the people bashing PEAR.php fail to take into account is that PEAR is one of the main reasons why are getting all these nice features into PHP5. So its kind of lame to be attacking PEAR that its a poor-mans PHP5. Without we will not be having the PHP5 we are having now.
Alot of people have said that PEAR claims to always have the perfect solution and not accept new ideas. This observation is incorrect. We want to provide high quality solutions. We also want to make life easy for our users. As such we dont accept redundant packages. So what is a redundant package?
Its a package that solves the same things as an existing package in the same manner. So if you have a new an unique approach the package is not considered to be redundant.
If your package follows the same approach we think it should be possible to merge the functionality into the existing package. This seems to be the real issue as developers are unwilling to go that extra mile. But I think gives us the benefit of not ending up with tons of packages that overlap needlessly.
It was also interesting to see that people said that they dont like the approach of PEAR to give alot of freedom to the developer of a given package. It was pointed out that a good core library needs to be driven by a core developer tema instead that can work on any part as they see fit. However if we allow tons of redundant packages in how is any team going to manage this?
We are taking a very different approach in our current effort to build up a QA team. SInce we dont have tons of redundant packages we actually have a chance of having a QA team watching over all packages. See the following RFC for details:
http://marc.theaimsgroup.com/?l=pear-de ... 710123&w=2
So all in all we do allow competition, but we also require a certain level of cooperation.
Regarding the comment on licensing. I dont see the issue. You may want to have a look at a recent group announcement where we explain our licensing policy a bit.:
http://pear.php.net/group/docs/20040402-la.php
Regarding error handling we are working to improve the situation. However I dont agree that error handling should not be handled inside the libs. Handling it outside is impossible. Take a look for example at the ondemand sequence generation inside DB. Its a good example of what you can do with this kind of error handling if you imagine for a second you would want to implement a similar feature outside of the DB package. For example you could automatically create a table inside your app. You can easily trap that single error (DB_ERROR_NO_SUCH_TABLE) and have special error handling here (create the table).
Of course PHP5 opens new possibilities, but remember again that PEAR was one of the main groups of people making sure that exceptions have made it into PHP5
I have briefly looked at some of the comments and I am in a very unique position to shed some light on things.
1) I am a member of the PEAR Group
2) I am also the lead developer of MDB
As such I am very much involved in what goes on in PEAR and I am also someone that came with an alternative to PEAR.
Anyways there is no rule in PEAR thats states that you need to extend PEAR. There is only the rule that you need to use PEAR error handling. This is a distinct difference which means that you dont need to extend PEAR at all.
One thing that alot of the people bashing PEAR.php fail to take into account is that PEAR is one of the main reasons why are getting all these nice features into PHP5. So its kind of lame to be attacking PEAR that its a poor-mans PHP5. Without we will not be having the PHP5 we are having now.
Alot of people have said that PEAR claims to always have the perfect solution and not accept new ideas. This observation is incorrect. We want to provide high quality solutions. We also want to make life easy for our users. As such we dont accept redundant packages. So what is a redundant package?
Its a package that solves the same things as an existing package in the same manner. So if you have a new an unique approach the package is not considered to be redundant.
If your package follows the same approach we think it should be possible to merge the functionality into the existing package. This seems to be the real issue as developers are unwilling to go that extra mile. But I think gives us the benefit of not ending up with tons of packages that overlap needlessly.
It was also interesting to see that people said that they dont like the approach of PEAR to give alot of freedom to the developer of a given package. It was pointed out that a good core library needs to be driven by a core developer tema instead that can work on any part as they see fit. However if we allow tons of redundant packages in how is any team going to manage this?
We are taking a very different approach in our current effort to build up a QA team. SInce we dont have tons of redundant packages we actually have a chance of having a QA team watching over all packages. See the following RFC for details:
http://marc.theaimsgroup.com/?l=pear-de ... 710123&w=2
So all in all we do allow competition, but we also require a certain level of cooperation.
Regarding the comment on licensing. I dont see the issue. You may want to have a look at a recent group announcement where we explain our licensing policy a bit.:
http://pear.php.net/group/docs/20040402-la.php
Regarding error handling we are working to improve the situation. However I dont agree that error handling should not be handled inside the libs. Handling it outside is impossible. Take a look for example at the ondemand sequence generation inside DB. Its a good example of what you can do with this kind of error handling if you imagine for a second you would want to implement a similar feature outside of the DB package. For example you could automatically create a table inside your app. You can easily trap that single error (DB_ERROR_NO_SUCH_TABLE) and have special error handling here (create the table).
Of course PHP5 opens new possibilities, but remember again that PEAR was one of the main groups of people making sure that exceptions have made it into PHP5
Ah I forgot to talk about the installer.
Its definately becoming more and more mature. Actually I would never have thought this to such a challenge but its not such a trivial process. However you dont need the installer. I generally bundle all PEAR packages with my application.
Back in the day we had alot of BC breaks, which we are addressing more and more and fewer cases are slipping through to the point where we are atleast as good as PHP about it (well they are not perfect either).
But I generally prefer to have every application self contained.
Anyways the PEAR installer is improving alot. Soon we will have channel support (which will make the installer even more interesting for other projects) and sometime we will even have application support. But nobody is stopping you from simply moving the files yourself if you dont care about dependency handling etc.
Its definately becoming more and more mature. Actually I would never have thought this to such a challenge but its not such a trivial process. However you dont need the installer. I generally bundle all PEAR packages with my application.
Back in the day we had alot of BC breaks, which we are addressing more and more and fewer cases are slipping through to the point where we are atleast as good as PHP about it (well they are not perfect either).
But I generally prefer to have every application self contained.
Anyways the PEAR installer is improving alot. Soon we will have channel support (which will make the installer even more interesting for other projects) and sometime we will even have application support. But nobody is stopping you from simply moving the files yourself if you dont care about dependency handling etc.