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

Hi, Gregory Beaver wrote:

PEAR2 is a repository of code that seeks to solve these problems:

Sorry, Greg, but these are not problems, these are goals or even mission statements (as in here: http://www.dilbert.com/comics/dilbert/games/career/bin/ms.cgi )

1) provide a simpler installation system than PEAR

PEAR isn't simple in the following areas: a) ... b) ... ... z) ... ?

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

3) provide a stronger coding community than PEAR

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

4) provide more flexible code that can be used in more settings

Current code is inflexible in the following settings: a) ... ... z) ... ?

5) provide better application support

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

6) provide a more rigorous standard for stable code

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

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

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

8) pay more conscious attention to performance as part of the goal to be flexible and attract more developers who will use this code in high-traffic situations

We already had developers who wanted to use PEAR in high traffic situations, but they didn't do it because...

Specific problems that have arisen recently include: * inability to easily relocate a PEAR installation Many people find it difficult to move a PEAR installation to another location on the same computer, or more importantly, to deploy it to a production server. There have been regular messages on pear-general dealing with problems of remotely installing PEAR, whether it is with PEAR_Frontend_Web on unix, PEAR_RemoteInstaller, or strange bundlings of PEAR files that break the relative locations of files, requiring odd include_path hacks.

We must be reading very different pear-general mailing lists, since the only references to RemoteInstaller I can find there are its release announcements: http://marc.info/?l=pear-general&w=2&r=1&s=remoteinstaller&q=b the situation with Frontend_Web is roughly the same: http://marc.info/?l=pear-general&w=2&r=1&s=frontend+web&q=b That being said, I support removing the possibility to separately set the php_dir / data_dir / test_dir / doc_dir and rely on relative paths here.

* difficulty bundling PEAR libraries inside applications not distributed through the PEAR installer It is generally more complex to bundle a PEAR library because the relative includes in require_once force the user to set up a relative include_path programmatically, and to ensure that there are no files with the same names (i.e. DB.php, for example) that would be loaded instead.

include_path is a non-issue here since we are speaking not of the newbies but of the developers who are already distributing their app with bundled PEAR packages. The second point can (and should) be fixed by prefixing, since having the files named DB.php and classes named Date is asking for trouble.

* 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. This was a real problem when PEAR was distributed as unzip-and-go with PHP rather than as installer, see the first question in QuickForm FAQ: http://pear.php.net/manual/en/package.html.html-quickform.intro-faq.php#AEN60110 After people began installing packages with the PEAR installer, such questions died out. I definitely don't look forward to their return. Maybe we should revisit the installer's output instead, so that it would be immediately obvious where is the installation it manages located?

* difficulty managing uncaught PEAR_Error We've all seen the posts like "I get fatal error: call to unknown method PEAR_Error->add(), but I asked for a Foo object!"

This was addressed long ago with the Exception RFC.

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

* 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?