a case for subpackages

From: Date: Mon, 25 Aug 2003 04:56:46 +0000
Subject: a case for subpackages
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-20474@lists.php.net to get a copy of this message
Hi, I'd like to make a case for subpackages in PEAR. First of all, the definition of a subpackage is dependency-based, and would not require any modification at all to package.dtd, or installation code (even the patch I provided for automatic dependency resolution would be unaffected). A subpackage is a package that depends on another package that optionally depends on the subpackage. In package.xml terms that means: Package Main's package.xml dependencies: <deps> <dep type="pkg" ... optional="yes">Main_Subpackage</dep> </deps> Package Main_Subpackage's package.xml dependencies: <deps> <dep type="pkg" ... optional="no">Main</dep> </deps> This relationship will never occur in a standard dependency. In practical terms, this means that subpackages must be uninstalled with the main package, but need not be installed with the main package. Obviously, anything that must be installed with the main package is either a standard dependency or a part of the main package itself. Subpackages by definition cannot exist as standalone packages - they depend on the main package to exist at all. A side effect of this definition is obvious: if one wants to uninstall the main package, it would be pointless to keep any subpackages installed, as they can't be used without the main package. There are countless examples. MDB drivers, phpDocumentor Converters, Log children, Cache containers - all of these are subpackages, and it should be possible to install some, all, or none of them (for the odd cases where a user only uses a custom driver/converter/container). Why separate subpackages from the main package? 1) Subpackages often have a very different stability level from the main package, and users who only want stable code should not be forced to read documentation just to determine the stability of a package. 2) Upgrading a subpackage that has changes is much more efficient in both time and bandwidth than upgrading the entire package at once. New subpackages can be released without a new release of the main package 3) Applications can depend on a minimal set of subpackages, reducing dependency bloat This patch implements subpackage handling for uninstall. If --nodeps is passed, subpackage uninstall will not occur. Note that the patch was made against CVS - if you wish to test both this and the auto-dependency-resolution patch, this one must be applied first, as all modifications to Installer.php in this patch occur after the install() method Greg

« previous php.pear.dev (#20474) next »