Re: real-world example of (smart) developers using PEAR without installation

Hi, Gregory Beaver wrote:

Having this file with no dependencies inside is even more stupid, as our hypothetical newbie will have to manage dependencies manually and this is a *very* non-trivial task for the package I mentioned above. After reading your messages to the list, I think the only reason we are having this discussion now is that some time ago you decided that it would be a good idea to have a single file for distributing phpDocumentor: both for unzip-and-go and for PEAR installer. And a lot of hacks later you can't just give up and say: "OK, let's have two different files to download and install that".

Actually, your choice of argument is quite interesting. For years, I maintained separate packages for phpDocumentor, one for unzip-and-go and one for installation via PEAR. This increased the complexity of a release tarball such that in several cases, the code didn't work in one of the releases quite right.

I am confused: you are mentioning the "separate packages" and then "complexity of *a* release tarball". Can you clarify what exactly were the problems?

Now that it is possible to do a tarball that works in both settings, the testing and development time has gone way down for phpDocumentor. So in spite of the vitriolic characterization of the work I've done (calling it "hacks" shows a lack of understanding, I think), there is no reason to give up - the idea works and it's worked quite well for a full year now.

Yes, and you also bundle outdated versions of HTML_TreeMenu and Smarty for PEAR-installed version of phpDocumentor instead of relying on dependencies handling of PEAR installer.

I can't quite tell if you intended to have a solution hidden in between the complains of your last message? Fortunately, I have limitless patience for potential solutions.

The solution I suggest is to provide "PEAR bundles" semi-independent of standard "PEAR packages". Instead of providing e.g. HTML_QuickForm_Renderer_Tableless package which bundles HTML_QuickForm and HTML_Common (which is stupid, since package's dependencies are several times larger than the package itself) we provide a "HTML_QuickForm bundle" which consists of HTML_QuickForm with HTML_Common and all QF's subpackages. This bundle may have a release schedule independent of the QuickForm package, it can be re-released each time any of the packages inside changes. With your approach we basically have to re-release a package each time its dependencies change, or else unzip-and-go people will have outdated dependencies.

For instance, I think a better way to handle user #1 who wants to try out a package is to re-focus the package page on pear.php.net for each package, as this is most likely the place they will go to download a package to try it out. Currently, we display a whole bunch of information, none of which is: 1) how to install the thing 2) how to use it (documentation or examples) For users who are not logged in as developers, these should be the absolute top priorities, with everything else further down the page. "how to install" should include a full list of possible dependencies with links to the latest releases compatible with this one, so that users can (if they desire) download all of them. It should also include the pyrus command to install the package, and a link to download pyrus. The "how to use it" would also include the code to get started: <?php // if you installed into /path/to include '/path/to/PEAR2/Autoload.php'; ?> These changes would limit the likelihood of a user having trouble.

I already wrote this sometime ago but it got buried in one of the threads... Installing the package is like 0.1%--1% of work required to use it. So dedicating insane amounts of our time to making this 0.1%--1% of work easier is not quite productive. This is a bit different with applications, of course.