Re: Patch: automatic dependency resolution, and new install options --alldeps and --allreqdeps

This is great stuff. Time ago I coded a real dependecy database for the installer (at php-src/pear/PEAR/DependencyDB.php), which was intented to suppport that. The code now only builds the database but does not yet support the handling of "complicated" cases. We could just drop that code and commit yours. Btw I'd change --allreqdeps with --onlydeps. Tomas V.V.Cox On Saturday, August 23, 2003 7:13, Greg Beaver wrote: > Hi, > As I mentioned a few days ago in another thread, I've been struggling > with how many dependencies phpDocumentor 2.0 can have on existing PEAR > packages, and how to solve this problem. Well, the solution to one > major stumbling block is attached to this email :). > The attached patch brings PEAR installation to the same level of > sophistication that apt possesses. For the first time, automatic > dependency resolution and install is possible. It is experimental, but > fully tested. I'd love it if a few brave souls would be willing to back > up their existing pear/PEAR directory and try this patch out, to assist > in the development. I'm also not particularly happy with the length of > the command-line to PEAR_Installer::download() and if anyone can see a > refinement, I've love to get that in here. Note that the patch was made > against the HEAD of php-src/pear, *NOT* version 1.2.1. > What does the patch do? > ----------------------- > * makes the order of packages passed to pear install/pear upgrade > unimportant > In previous versions this would fail: > pear install HTTP_Request Net_URL > With this patch, it correctly switches the install order so that > dependencies are installed first. > * adds the new install options --alldeps and --allreqdeps > --alldeps instructs pear to recursively find and install all required > and all optional dependencies > --allreqdeps instructs pear to recursively find and install all required > dependencies only > usage example: pear install --alldeps SOAP > usage example: pear install --a SOAP > These examples will find the dependencies of SOAP: Mail_Mime, > HTTP_Request, Net_URL, and Net_DIME and download them. > Then it will find all the dependencies of the dependencies, and download > Net_Socket as a result (Net_URL will not be downloaded twice). If any > of these dependencies are installed and up to date, they will not be > downloaded. If they are installed and not up to date, they will be > upgraded. > Finally, the packages will be sorted into the order needed to install > them, and installed. I've tested with both Cache (3 levels of > dependency) and SOAP (2 levels plus common dependency across levels) > usage example: pear install --allreqdeps > pearcvs/pear/Perm_LiveUser/package.xml > usage example: pear install --A pearcvs/pear/Perm_LiveUser/package.xml > These examples assume pearcvs/ is a cvs checkout of the pear/ module > from cvs.php.net > This one will install LiveUser 0.8 from CVS, and skip the download and > install of MDB, DB and HTTP_Request > * splits PEAR_Installer::install() into 3 methods: private > _downloadFile(), public download() and public install(). This split > allows the download of all files prior to any installation attempt, to > allow full dependency resolution and sorting for installation. > * Numerous important failure tests > - failure on package not existing, or having no releases yet > - failure if the preferred state is too high for dependencies to be > installed (Net_DIME only has beta releases, for example, so if > preferred_state is stable, it will fail on installation) > What doesn't the patch do? > -------------------------- > * Major issue: no check for major version upgrade/install - waiting for > resolution on how major upgrade/install will be handled (this is an > existing issue in the pear installer, so I decided not to "fix" it) > * No change is made to pear uninstall. > "pear uninstall Net_URL HTTP_Request" will still fail due to incorrect > ordering of packages on the command-line, and "pear uninstall SOAP" will > not attempt to uninstall any dependencies. I didn't feel comfortable > with the safety of adding --alldeps or --allreqdeps to uninstall, but if > there is a demand for it, it can be easily added. (uninstalling > dependencies is MUCH simpler than installing them). > :) > Greg -- Tomas V.V.Cox mailto:cox@idecnet.com