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

Hi, Greg Beaver wrote:

I'd like to suggest a mental exercise. Here is a package from current PEAR: http://pear.php.net/package/DB_DataObject_FormBuilder/ Now let's consider a hypothetical developer who downloads the hypothetical PEAR2_DB2_Dataobject2_FormBuilder2 without using the Pyrus installer. Please outline the steps he will need to perform before he is actually able to use said package.

This is a great way to explore the problem the new system introduces and how it could be solved. First, I would like to back up and ask why this hypothetical developer would be using a PEAR2 package without having it installed. There are two use cases that I have seen in the real world: 1) trying out a package 2) bundling a package within another application with its own source repository. For user #1, a package of just the PEAR2_DB_DataObject_FormBuilder (I doubt we'll need more than the 2 in PEAR2) would not be super useful. They would need to download each and every dependency, and to figure this out somehow. This user would instead want a download that contains bundled latest releases of each dependency. This could be done automatically at package time, or a separate bundle could be automatically created at upload using package.xml 2.0's bundle feature. The advantage of bundling dependencies inside the release is you have 1 download, it's simple to see what to get. The disadvantage is that it increases the download time and package size needlessly for those using pyrus, which would ignore the bundled dependencies (they wouldn't be in package.xml).

Yes, that's exactly the point I was getting to. We *may* need *different* ways to distribute packages, but you are trying to shoehorn everything into the single Foo.tar.gz file. Having this file with all dependencies inside is just plain stupid: $ pyrus install PEAR2_HTML_QuickForm Ok, we have P2_QF installed $ pyrus install PEAR2_HTML_QuickForm_Controller Now we download P2_QF the second time... $ pyrus install PEAR2_DB_DataObject_FormBuilder Now we download P2_QF the third time... And what version of P2_QF do we have installed after these steps?.. 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".

For user #2, again it would be a bit annoying to download each dependency, but I suspect the user could be enticed into using the pyrus installer to manage the installation if we provide a special "no registry" option. As package.xml is now a part of the registry (and is named in the special format package-channel-PackageName-version.xml or something similar to that, I'm not quoting source code, but am remembering what I coded last April), and so it is possible to "upgrade" an extracted package without needing it to be registered, as the registry could be constructed on the fly from the package-*.xml in the php_dir. Still, the installation would need to work without having the guys of pyrus - the registry and configuration file - present, which essentially makes it the same as unzip-and-go.

Yes, exactly, user #2 will have to use a build tool, be it pyrus, phing or something else still. Or he can download the file with all dependencies inside, optimized for *not* being installed via Pyrus.