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

Alexey Borzov wrote: > 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) ... > ? PEAR Installer is not simple in that in order to even try out a package, an installer must be downloaded and installed with extensive configuration, root access is often required just to get started, configuration is confusing, registry is not human-readable, and a completely unrelated php.ini variable (include_path) must be configured properly before the first line of code successfully executes. >> 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. >> 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. 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. 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. >> 4) provide more flexible code that can be used in more settings > > Current code is inflexible in the following settings: > a) ... > ... > z) ... > ? As I have said many times, the current code has hard-coded relative require_once calls that limit PEAR to the include_path-based installation, use replacements and hard-coded paths in the registry that make it difficult to deploy or relocate a PEAR installation. >> 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." >> 6) provide a more rigorous standard for stable code > > which isn't possible with the current PEAR because... ...there is no review of API, tests, or documentation prior to a stable release. >> 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. PEAR does not provide a safe or relaxed environment in which to innovate because in order to propose a new package, you must first: 1) apply for an account 2) apply for a PEPr proposal with completed code 3) wait 1 week minimum for comments 4) wait for votes for 1 week 5) when approved, apply for a CVS account 6) wait... 7) get CVS karma The new system proposes something like: 1) apply for an account 2) apply for PEPr proposal with idea and propose it for development 4) wait for votes for 1 week 5) get SVN account at svn.pear.php.net 6) begin development 7) work without limits until package is ready for beta status, then undergo code review >> 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... Many PEAR packages pay absolutely no attention to performance? require_once adds significant drain on performance even in APC environment, and the use of PEAR_Error and PEAR base class imposed noticeable performance drains for many developers because of emulation of destructors and the extra penalties of static method calls for checking on error conditions (isError()). >> 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 The messages I am referring to often don't mention PEAR_RemoteInstaller or PEAR_Frontend_Web. Usually they say things like "Why can't I erase files installed by PEAR?" (PEAR_Frontend_Web issue when run on unix with permissions set to 0666, the default setting), there was a message recently where someone was trying to use an HTML_QuickForm that had been installed all into the same directory, breaking the relative require_once calls. Things of this nature are harder to find with a straight keyword search, but they have popped up with surprising regularity. > 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. 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. > 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? Again, just because it will be possible to use a package as unzip-and-go does not make it the recommended way to use PEAR2 packages. Pyrus will be so much easier to install than the PEAR Installer that most people will be comfortable simply downloading it and using it. However, some users will benefit from the added flexibility of not needing to install a package in order to use it. Making this possible does not mark the end of the world, nor the beginning of the return to issues like the one above. If the scenario above is what you're worried about, I understand where all the fear is coming from. >> * 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. 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. 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? > >> * 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. :) As I said in the reply to your more recent message, the proposed solution is more flexible than simply cramming into one file. Yes, it would allow packages to be crammed into a single file, but it also allows them to run off disk the normal way, to be put into a phar archive without modification, and even to be crammed into a single directory without any relative path hierarchy (not that I would *ever* consider doing this, but it's hard to predict the future with 100% accuracy, isn't it?). All of this flexibility simply from the removal of a require_once statement at the top of each file. Greg