Re: Re: PEAR2 standards: anything good at all?

Hi, Lukas Kahwe Smith wrote:

First of all, many applications right now are bundling PEAR packages, so that is definitely possible. Next, unzip-and-go isn't required for making packages easier to bundle. I don't think that you'll have any problems with copying installed packages from the local PEAR installation (you have one, right?) to your application directory. Of course, there is a question of fixing paths within packages, but unzip-and-go isn't quite an answer for that, some better answers were proposed.

Alexey, what exactly are you arguing against. Are you concerned about the overhead of __autoload()? Please step back a second, we are not disallowing the use of require_once in your app code, we are not forcing you to use allfiles.php. All we are doing is decoupling the loading of code from the implementation. This gives us the flexibility to let people load the code that makes sense to them, instead of us forcing them to a particular approach.

If the "Standards" proposal started with a reference implementation of PEAR2_Loader class that'll "decouple the loading from implementation", including the reference implementation of __autoload(), that would be a good idea. But instead we see some ugly spaghetti that is supposed to be copy-and-pasted and vague references to __autoload() that's supposed to be written by a end user (who is also supposedly unable to setup include_path). Also we see quite questionable reasoning quoting APC. I'm not against the decoupling idea, BTW. But the state of "PEAR2 Standards" is so bad that it'd better be scrapped and started anew.

As for unzip & go, while I agree that the use case is questionable, nothing we are planning for this is really going to cause any drawbacks. Doing all possible file and dir adjustments at packaging time is a good idea at any rate. It doesn't hurt at the very least and adds some transparency and easy verification that things were setup properly. We will not remove features over this.

The whole idea of unzip-and-go is a major drawback. Write a package manager that is at last capable of handling dependencies and then return to manual handling of said dependencies looks like a major drawback to me.