Re: PEAR2 standards: anything good at all?

Adam Ashley wrote:

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?

The huge difference is that if you don't understand the serialization format used by PHP when you do that search and replace you will stuff up your pear config.

Good point. Well, another question is whether installation relocation is such a common task. And why most package managers do not support it, then.

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? * Anyone else smelling a reincarnation of PEAR_Error here?

Namespaces where only confirmed to be in PHP6 within the last week, you know after the currently proposed standards where written. I fully expect to see another RFC with namespace support before its all said and done. Also recall that PHP5 CVS had namespaces for quite a while. My initial test ports to PHP5 used them and they worked quite well. Notice the amount of namespace support in PHP5 now. APC is out there and working and quite common on big setups, acknowledging it is quite acceptable. Acknowledging namespace support which at its best is an unsupported patch is another thing entirely. I've wanted namespace support for a long time but i'm not going to get my hopes up or plan around it until it actually makes a release.

You didn't quite address the questions: * Should we optimize for third-party apps? * Should we work around problems in third party apps? If answer to both questions is "yes", then how do we decide whether to optimize and work around problems in a particular third-party app? Especially bearing in mind, that said app may change a lot in the future and we have no control over it?

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).

How about you assume for a moment that the people who care about things like microseconds wasted on require_once know how to setup a server to prevent obvious things like it swapping continuously.

We aren't targeting just for people who care about microseconds. How about PEAR banned on shared hostings due to excessive resource usage?

My reading of the proposed standards is that its about giving folks CHOICE in how they do something. If they want to unzip-and-go they can, if they want to run it from a self-contained pacakge (sorry i forget what they're called) they can, if they want to let pear install it then include one file and it just works they can, if they want to get every microsecond they can out of the code to support millions of hits a minute they can. It is NOT about enacting the 'Alexey Borzov way to do PEAR' and everything else be damned.

Well, you are definitely flattening me, this "Alexey Borzov way" is used by quite a number of libraries and frameworks. My point (and that of several other developers) is that creating a proper package is a job of a packaging / building tool, having one-size-fits-all package is not feasible. Have you ever downloaded a program that'll be installable by both RPM, MSI and runnable by just unzipping the file?

And to get back to your original point which you never seemed to manage, what about the rest of the document? You covered maybe 3 points.

The rest of the document basically belongs to my category 1: nonexisting problems.

* Prefixing packages - Absolutely needed. Whether it is a prefix in the class name or a namespace doesn't matter, thats implementation and can fixed later depending upon PHP features that actually make it to release.

Have you seen this? http://pear.php.net/pepr/pepr-proposal-show.php?id=420

* Standardised directory structure - Yes it's not needed, yes some people will bitch. The people that wont are those trying to figure out a package to find what they are looking for. You know future developers, bug reporters, ie people we want to make it easier for.

I don't think I need a contributor for any of my packages who is unable to find a file. Do you?

* Class-to-file conversion - Again consistency, see previous item. Currently its just recommended make it required is a good thing.

OK, so it's a clearer re-wording of existing standards that are (mostly) respected anyway.

* Base exception class - Yay consistency, notice a theme here yet? Make it easy to figure out where this exception came from.

Though it is already required by current coding standards: " Aditionally, each PEAR package must provide a top level exception, named <Package_Name>_Exception." http://pear.php.net/manual/en/standards.errors.php

* Handling of Dependancies - Someone in one of these threads mentioned that the error message given out by PHP when it can't find a file to find is more than adequate. That person obviously has never spent anytime on IRC fielding questions about why MDB2 fails with a Fatal Error including MDB2_driver_mysql. An exception explicitly stating what is happening is much more useful.

The problem here is that MDB2 throws a PEAR_Error that [theoretically should] explicitly state what's happening, but is way too easy to ignore. That'll be a non issue for PHP5 packages that will throw an Exception.

* Data files - Take a look at something like HTML_AJAX with its crapload of support javascript files, and its funky data dir lookup code, which includes a hard coded '/usr/share/pear/data' and then tell me its not needed.

In fact HTML_AJAX relies on @data_dir@ substitution and also tries to handle the case when that substitution wasn't done (effectively supporting unzip-and-go-somewhere).

* General Policy Rules - about time they've been written down, coming in as a new developer you can't find out about these rules until you break em.

Yeah, these are good, but should be published and discussed separately. That's why I din't touch them.