Summary: dependencies and Applications

OK, here is an attempted summary of the ideas that were ruled at the very least feasible: #1) (Many people) Immediately move all packages into directories separated by major version number PhpDocumentor 1.x would be in PEAR/1.0/PhpDocumentor PhpDocumentor 2.x woudl be in PEAR/2.0/PhpDocumentor have a placeholder file named PhpDocumentor.php which contains this code: <?php trigger_error('WARNING: require_once "PhpDocumentor.php" is deprecated, use require_once "PEAR/majorversion/PhpDocumentor.php" as in require_once "PEAR/1/PhpDocumentor.php"', E_USER_WARNING); define('INCLUDE_PATH_SEPARATOR', substr(PHP_OS, 0, 3) == 'WIN' ? ';' : ':'); // set the include path so that it works without modification to the package // this will not work on some systems, so it may be best to instead modify a package set_include_path(dirname(__FILE__) . '/1' . INCLUDE_PATH_SEPARATOR . get_include_path()); ?> #2) (Alex) create two commands, pear-lib and pear-app. pear-lib is for installing packages, and pear-app is for installing applications. To quote Alex: pear-app checks the deps of myDBAdmin, and find such thing like "require DB 1.x". It checks with pear-lib if this version is installed; and it registers in the pear-lib registry, that an application requires an 1.x version. two months later: you update DB to 2.0 pear-lib upgrade DB pear-lib see, that this a new major version and checks its registry, if there are any dependencies of apps requirering a lower major version. If this is true, it copies the current installed 1.3 version to the base dir of the applications. #3) (Jan Schneider) Keep the current directory structure for all existing apps. Switch to the new directory structure for for the next major version number of existing applications. No BC breakage at all. #4) (Lukas) Use symlinks for applications on linux, and multiple package copies on Windows: The PEAR Installer for applications installs the pear packages that are needed into a seperate directory. This means that code is installed multiple times which means increased hard drive use and wasted ram for byte code caches. However on *nix platforms we can use symlinks instead. I don't know however how byte code caches handle symlinks, but maybe they cache the file only once (and if they don't this might be a nice new feature unless I am missing something). #5) (Greg) Seeing all of these, I think that the combination of #3 and #1 makes sense. Dynamic setting of include_path does not always work, so it is unfortunately unreliable - packages must be aware that they have to use the major version number for this to work. In addition, Jan is right - existing apps/packages work just fine with the existing structure, the only issue is a BC break upgrade. So, I propose this refinement and combination of all ideas: -current major versions would remain exactly the same. No need for the little script of #1 -the next major version of a package would be installed to directory PEAR/Package/vX where X is the major version number (PEAR/MDB/v2). -internal paths should be calculated using dirname() and __FILE__ (a relative path of the parent directory can be found with dirname(dirname(__FILE__)) -the addition of a new command "revert" - if you run a "pear upgrade package", and everything breaks that was working, the "pear revert package" command would revert your upgrade back to the last working install. -the addition of a new script pear-app which will handle application installs. This script would use a different installer and process an application.xml file. The application.xml could allow dependencies on both PEAR repositories and other repositories, but these details can be worked out separately from this thread. These changes should make dependencies much more reliable. Greg