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

Hi, Alexey Borzov wrote: > 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?.. the one from PEAR2_HTML_QuickForm. As I said above in the part you quoted, the files not in package.xml would be ignored. > 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. 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. The proposed changes simply make it easier to execute this idea without impeding normal development. 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. 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. We might consider making the package page more wiki-ish in the sense that a package developer could edit the example code >> 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. the thing is, with the proposed changes, this would be the same thing - no need for double maintenance. The same package would also be optimized for use from within a phar archive without code changes, and the same package would be optimized for use from within a single large file. The same package would be optimized for installation with and use by the PEAR way too: include_path-based includes. All without a single line of code needing modification. Greg