Re: Summary: dependencies and Applications

Hi Alan, Alan Knowles wrote:

Greg Beaver wrote:

-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).

I'm still not conviced that this is necessary it creates more problems than it solves, opens a huge can of worms, and ruins one of the key attractions of pear, that locating source code is directly related to class name.

So how would you propose solving this? If there is one source tree, that means all packages/applications that use an application are required to upgrade when there is a BC break, or they will stop working. If there are different source trees for different major versions, how should they be named? I also don't follow how the connection to classname is lost. The connection is maintained, there is just an additional connection to major version that is added.

-internal paths should be calculated using dirname() and __FILE__ (a relative path of the parent directory can be found with dirname(dirname(__FILE__)) this has be discussed many times.. - and the explained many times why it's not a good idea.

All I see here is that the solution I proposed works just fine. Unless __FILE__ is inconsistent and dirname() is not present on every platform it will work 100% of the time. If you're really against this, then it's simple enough to keep relative paths and use the same directory structure in CVS (which would make sense) the way Richard has with Mail_Mime 2.0. In this case, every file would need: require_once 'Package/v2/Sub/Name/File.php'; instead of require_once 'Package/Sub/Name/File.php'; Of course, your objection is to the internal v2. In this case, we could follow a modification of Davey's suggestion require_once 'Package/v2/Package/Sub/Name/File.php'; I think we can preserve one of PEAR's most attractive features and eliminate one of its most ugly problems without making anyone unhappy :).

set_include_path(dirname(__FILE__) . '../;' . get_include_path()); In your application's core 'common.php' file works 100% of the time in PHP4.3 to solve locating files for alternative versions of pear files. (the ini_get/set version works on most hosters.. of older versions)

most is not the same as all - and when there is a solution that works on all hosts, that is a better solution.

-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.

sounds plausible.. - involves setting up a transaction history in the registry I guess. its already posible to install older versions using pear --installroot=/my/application install

      http://pear.php.net/get/DB-1.2.tgz

-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.

not sure why the package.xml cant be extended for this.. - there appears to be only a few minor features required..

It can be, but I think it would be a good idea to name it application.xml, and define application.dtd simply because of the confusion factor, IMO, and this will also allow for extensibility. Applications need much more customization than packages, and there will always be things that were not foreseen. Greg