Re: PEAR2 standards: anything good at all?

Alexey Borzov wrote: > Hi, > > After re-reading the "PEAR2 standards", "PEAR2 require" wiki pages and > (most of) discussion on pear-dev, I'm beginning to think that these > so-called standards should be ditched in their entirety. > > The problems that PEAR2 is supposedly trying to solve can be easily put > into three categories: > 1) Nonexisting > 2) Caused by tools outside PEAR > 3) Those having solutions much worse than the problem itself > > > It is claimed that unzip-and-go is a good thing. But let's think aloud: Correction: unzip-and-go is what the majority of PHP users understand and expect from a PHP library. I hate unzip-and-go, but I do like getting users to try things that leads them to understand the installer is a good thing and start using it themselves. > who is the target audience for unzip-and-go? I suppose these are the people > * unable to use PEAR installer (those who don't *want* to set up a PEAR > installer on the server may use its remote installation capabilities) > * unable to set up their include_path (which is a pretty standard task > among programming languages) > > So we provide a way for these people to not use a PEAR installer and not > set up an include_path, but "Of course, the people need to take care > about dependencies themselves if they do not use Pyrus." > > O-o-o-kay, now let's think aloud again, what are the chances that a > person unable to set up an include_path will be able to properly take > care about dependencies? I'd say close to zero. So we'll have way more > stupid questions on pear-general and more bogus bugs in the tracker. As many others have mentioned, this is a task for a build tool, and although not verbalized, I planned to have the ability to create packages that contain the current dependency's files, with the nice touch that the installer would simply ignore them, so that only unzip-and-go users would see them. However, rather than think innovatively, it seems you are content doing the "gee what a stupid idea this RFC is" thing, cluttering the mailing list for no good reason with clever things like "O-o-o-kay, now let's think aloud again". > Also please note that several PEAR packages were once provided as > unzip-and-go with PHP (instead of bootstrapper for PEAR), some of the > developers should still remember what a support nightmare that was. > > > Now another "problem" is that PEAR installation is not relocatable. > Since we already covered unzip-and go, let's presume that we are talking > a real installation here. The proposed solution is to have a > data_dir.txt file in the installation root that'll contain the name of > data directory. Nice. > > But if I relocate the installation, will the file automagically contain > the name of the dir I relocated to? No? So, is there a huge difference > between editing this file by hand and doing a mass search-and replace > that's required now? Again, you fail to think even creatively here. The relocation would be only be performable through Pyrus, but in a pinch, a hand-editing of the paths in the .txt files would be a possibility, something that is technically impossible with the current registry design of PEAR. The search-and-replace will not work for the simple reason that once the registry is corrupted, you can't upgrade anything at the new location. > require_once controversy was already covered a lot here, my opinion is: > * slow require_once in APC is a problem of APC, not PEAR. APC > developers are aware of it and are solving it, so sometime our > optimizations may become counter-productive. > * require_once is faster without APC. If we're targeting PHP6 which > will (supposedly) have APC built in, why aren't we using namespaces, > too, going instead for PEAR2_Obnoxiously_Long_Class_Names? Alexey, namespaces were announced what, a week ago? This RFC was written long before the proposal for namespaces. I for one would love to target PHP 6 for PEAR2, as we could finally drop the Long_Names. Again, however, rather than propose this as a (very interesting) solution, you choose the language of the helpless victim "why are they not doing this thing?" > * Anyone else smelling a reincarnation of PEAR_Error here? > > Also people were talking a lot about "speed improvements". Let's not > forget about memory: if we fill up the server's memory with dozens of > useless classes and begin to swap, we'll have more serious problems than > a couple of microseconds wasted on require_once (this is mentioned on > "PEAR2 require", though). Of course memory is an issue. For your information, the most often changed part of the RFC has been the allfiles.php solution. All new ideas need lots of battering before they can be considered well thought-out, and this is no different. The basic misunderstandings I see are: 1) you think we're out to get you, or at least out to get some people you care about and think we don't care about (I wish I could help more on this point, but it's out of my hands) 2) you think that any of these ideas are set in stone 3) you don't think any of the problems trying to be solved are worth looking at for two seconds. I will bend infinitely on implementation, but I will fight to the death to get the problems solved in a way that makes everyone happy. Yes, I do believe we can keep things working fantastically for the most entrenched PEARy (i.e. Alan, who relies on PEAR for specific tasks and is used to require_once) and for an external folk who would benefit a lot from PEAR. As for all the flailing about with benchmarks and such, I think we can agree that every proper benchmark shows that cramming stuff into a single file is faster than lots of relative require_once with circular require_once calls with many files. The point of the require_once thing is to give users much more flexibility about how they use PEAR, and the main goal is to give this flexibility without removing any security or debug-ability. It may require changes to the way things are done, but I do not want to see any reduction in this, and if you find a problem (like examples/tests) I appreciate the feedback in the form of "but what about examples? How will they know where to load files?" This is far better than being churlish, and will actually spark *useful* debate. The problems I see with this are the same problems you and Alan see. This is why I originally proposed that class dependencies be documented at the top of files with if (!class_exists('Classname', true)) simply because this would force the autoloading at the top of each file, and make it far easier to debug a missing file than the current fatal error on require_once. As I wrote in a reply to Matthew, the timing of the proposal was unfortunate, as Arnaud expected a reasonable response to a call for feedback, which turned out to be naive at best. This is an unfortunate indictment of PEAR, however, and brings up long histories of decisions being handed down from above. Let it be said many times: THIS IS DIFFERENT NOW, WE WANT COMMUNITY INVOLVEMENT IN THE DECISIONS. Please try to understand that we also don't expect the community to do our work for us - the PEAR Group + PEAR president are dedicated to devoting *more* time than you all are to solving large problems of managing this PEAR beast so you can spend more time on coding. This sometimes means that decisions have to be made, but it also means that your feedback *can* be helpful in shaping these decisions so it benefits you. It is your choice as to whether you will indeed help or instead resort to calls to stop innovating. Thanks, Greg P.S. I don't understand the PEAR_Error reference. PEAR_Error is dead in PEAR2, unless you're referring to PEAR_Exception? I am not married to requiring PEAR_Exception, it just seems people like the thing. P.P.S. I have a sample PEAR2_Autoload implementation in subversion for Pyrus, http://svn.pear.php.net/PEAR2/Pyrus/trunk/Autoload.php