Re: What are the problems PEAR2 seeks to solve? [and a solution to the require_once debacle]

Hi, Gregory Beaver wrote:

2) provide code that takes advantage of the best new features in PHP 5 and beyond

which isn't possible with the current PEAR because...

This is possible with the current PEAR, but not in the current PEAR Installer, which must remain backwards compatible with PHP 4.

Thanks for clarification.

3) provide a stronger coding community than PEAR

Current coding community isn't strong enough in the following areas: a) ... b) ... ... z) ... ?

Current coding community encourages apathy once a package is accepted because there are no demands placed on implementing tests or documentation prior to a stable release, the only review is done at package proposal, and developers are not encouraged or required to collaborate on packages.

Agree here.

Instead, the lead developer has absolute control to the point that even the QA group must wait a long time before fixing a package with critical bugs.

This actually makes sense now, since without tests to define the behaviour it is dangerous to allow anyone to "fix bugs" in fact introducing dozens of new ones.

In addition, collaboration on API is non-existent, each package is on its own, with no encouragement to collaborate on interoperability of libraries, even though PEAR's purpose is to provide libraries to plug in for solutions.

Don't agree here, as you'll only get API collaboration if you design PEAR as a framework rather than a collection of packages. On the other hand, PEAR has some well depended-upon packages even now.

5) provide better application support

PEAR application support lacks in the following areas: a) ... ... z) ... ?

PEAR lacks application support in the areas of simply dropping in PEAR packages to a non-PEAR application because of the strong dependence on relative include_path for loading files. PEAR also makes it harder for applications that often are distributed as "download this, unzip it, and run the configuration script" to have dependencies on PEAR packages, as most users will not do "download this, install the PEAR Installer, install a bunch of packages, run the configuration script."

Umm, in *nix land you either use a package manager for all your apps or download a .tar.gz, run a ./configure script and that script complains if it can't find something it needs. If you install something commercial then it comes as a bundle with most of its dependencies inside. As I already said, you are trying to mix these approaches.

7) provide a safer and more relaxed environment in which to innovate

That part must've come directly from Dilbert mission statement generator.

Now there's a helpful criticism, thanks Alexey. I'm sure the rest of pear-dev is really glad you contributed this useful and brilliant idea to the discourse.

Sorry, but these were just generic words that I couldn't tie to anything at all. With your clarification I now understand the specific problem you were addressing.

* difficulty managing multiple PEAR installations This has been a problem most often when users on unix have a system PEAR installation and a local installation, or other similar setups where include_path points at the wrong installation, making it look like packages have been installed that have not otherwise been installed.

...and the proposed solution here is allowing the unzip-and-go installation, which will lead to yet another copy of the package, not appearing in either of "pear list" commands. Nice.

No, the proposed solution is not allowing unzip-and-go. The proposed solution is a Pyrus-only solution: to more closely link the registry to include_path, so that it is harder to install a package in a random location, or to support passing in a path that pyrus should install/update the package directly. Unzip-and-go is unrelated to this problem.

Thanks for clarification.

* great difficulty re-bundling a PEAR package into another non-PEAR format Some examples: any phar archive, go-pear, installation scripts for web applications that require PEAR like blogs. Many people asking for technical support are having trouble understanding how their application expects them to set up include_path because it is not immediately apparent where the files should be, or why the application is not detecting their properly installed PEAR repository and so on, which is evidence that the web application authors also had difficulty with this question of re-bundling PEAR or externally requiring it.

The solution to include_path problems is educating people about it not dropping the include_path. Building the distribution is the job of the special build tools, this shouldn't be forced on the package authors. Most of the Open Source projects just provide a source tarball, you don't expect them to provide a file that will be installable with both RPM, MSI and also directly runnable on 15 platforms.

Again, nothing in this proposal suggests or encourages dropping include_path! Packages will still be distributed in exactly the same layout as before, relative to php_dir. In fact, the work done at installation time of doing baseinstalldir will be done at packaging time, so that the distributed packages are identical in most cases to how they will look on-disk.

OK, thanks for clarification, the problem is the initial advocacy efforts for this proposal mentioned how "include_path is hard" and we should get rid of it.

The *only* removal is require_once, which has no relevance to include_path, nor to the question of dependencies. By making it possible to add unrelated files (dependencies) to a package archive, this adds the possibility of using a package without installation, it does not remove any of the existing benefits of PEAR. This also need not impede the normal way of doing things: * develop * prepare package.xml for release * package * upload Developers may not even notice a difference beyond the removal of require_once and using PEAR2_Autoload for development or some other custom include() solution. Are these ideas making more sense yet?

Yes, they do, but I still have issues with the exact solution proposed.

* complications making code based on PEAR opcode-cacheable This point has been hashed and re-hashed on the mailing lists, and I don't wish to pick at old scabs if possible, but will clarify if asked (again).

If we don't go a "one package --- one file" path, then we are not performance conscious enough. Why settle for a half-solution when the full solution is available?

You can't be for this and also against removing require_once. :)

I'm not exactly against removing require_once, I'm against juggling "10% faster" arguments. I'll respond to other points in the other thread, "smart developers".