Re: dependencies and applications

Greg, I have a few comments on what you've said: Firstly, as you (should) know, packages of the same major version should always have a compatible API and be full backwards compatible. So what we really need is a) for rel="ge" to only pertain to that major version or b) another relationship that makes it only pertain to that major version Secondly, we need to make sure that *all* dependencies are resolved, so that when you first type "pear install phpDocumentor", it will find its own dependencies, then their dependencies and so forth. Lastly, we need to think about having some sort of "slot" system such as they have in Gentoo for their ports, whereby you can install more than one major version of an application. This will mean some changes to the folder structure, and if it happens should be done ASAP so that we can just get the change over and done with IMO. I suggest something along the lines of: $php_dir/pear/MDB/1.0/MDB.php and $php_dir/pear/MDB/2.0/MDB.php Using MDB as an example purely because its coming up for a major version change ;) We could perhaps put the current stable version in $php_dir/pear/MDB/MDB.php as it is now, but you run the risk of api breaking between major (but stable) versions... I don't think I like this. - Davey Greg Beaver wrote:

Hi, I've been grappling with some problems relating to the use of PEAR packages in phpDocumentor 2.0 that are stopping development dead in its tracks, and I'm not sure how to resolve them. We'd like to use the code from several packages in PEAR that are well-written and solve problems that have plagued version 1.0. For instance, class inheritance is a very complicated tree that would be handled very well with the help of a package like Tree. HTML_TreeMenu is useful for the web interface. Cache would be useful for caching parsed output, and so on. To use these three packages would require us first of all to depend on a specific version (no rel="ge"), since any upgrade to a package that breaks BC would break the whole application. First of all, this introduces required dependencies on DB, HTTP_Request, Net_URL, XML_Parser, HTML_TreeMenu, and Cache. the dependency requirement happens to be a semi-complex tree, and the user would go through this process before successfully installing: pear install PhpDocumentor downloading a bazillion bytes.... requires DB, Cache pear install DB Cache successful Cache requires HTTP_Request pear install HTTP_Request Cache HTTP_Request requires Net_URL This is very frustrating - 3 install attempts and we're still not able to install phpDocumentor Here's the problem: imagine another application is desired which depends on version 3.0 of Tree, and phpDocumentor depends on 2.5. Upgrading to 3.0 would kill phpDocumentor, and the other app won't work with 2.5. The user is forced to wait for an upgrade to phpDocumentor in order to use the other application. Instead, he or she abandons PEAR in frustration. This could be solved by distinguishing between extensions and applications. PEAR is designed strictly for extensions now (PER as Harry stated). Applications need to be handled separately, and I would suggest that all applications would need their own local copy of global packages. In the code, the difference would be: // require the app-specific package require_once 'packages/DB.php'; or with Heine's idea, require_once 'packages/PEAR/DB.php'; Obviously, for required dependencies, this is silly - the version should simply be bundled, end of story. The problem arises with the PhpDocumentor_Lite idea. Optional dependencies would require the addition of a new subpackage consisting solely of a copy of a specific package. This redundancy seems to me to be against the concept of a repository of re-usable components. With a large number of applications, there could be 5 or 6 copies of the same package floating around re-bundled as subpackages! Things would get really confusing. In addition, in many cases, upgrading the other package would actually be OK - releasing a whole new version of an application would be unnecessary (especially if packages strictly follow the versioning conventions, and don't change ANYTHING about an API from version 1.x to 1.x+1). In addition, as another example, PhpDocumentor will never, ever use the HTTP_Request feature of Cache (which should be an optional dependency), and so it would be good to specify which optional dependencies of a dependent package should be installed for an application. Looking at these problems, there are two solutions that pop into mind. 1) packages need to have subpackages. There are many examples of large classes in PEAR that all serve many useful purposes, but most users/applications will never use all of them at once. I find myself again and again saying "ooh that would be useful if it weren't so humongous, since I only need this tiny portion of it." It doesn't make sense to split these packages up into several packages with dependencies, that would only make it harder to find them on the website. Instead, there need to be subpackages. This will solve one other really serious issue: different subpackages always have different stability levels. For a while, the core of phpDocumentor and the HTML converters were stable, but hte PDF converter was Beta quality, and the DocBook converter was alpha. It is impossible to express this state difference except in a README file, and it would be much better to express it using meta-data, so the installer can handle requests to install only stable packages correctly. 2) if PEAR is going to ever handle applications properly, there needs to be a separate namespace, and a separate .xml file, application.xml. We simply will never be able to release phpDocumentor 2.0 unless the problems of dependencies can be worked out. As it stands, our hands are tied. I can't make phpDocumentor_lite depend on 10 different projects and expect it to work for more than a month, when the first BC break happens in a dependency :). I know PHP 4.3.3 is about to be released, but that is why it is a perfect time to start thinking about where PEAR is heading - will PEAR ever truly be a PEAR or just a PER? It's time to decide this so that another solution can be written for applications that co-exists with PEAR if not. Greg