RE: [PEAR-DEV] dependencies and applications

> From: Greg Beaver [mailto:greg@chiaraquartet.net] > Sent: Wednesday, August 20, 2003 11:17 PM > > 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. As was pointed out this means that we need to ensure that BC breaks only happen with major version upgrades and we also need to make it possible to define in the package.xml which major version are compatible (or something along those lines - maybe defining requires major version 2 or 3; or defining compatible with versions 1.2 through 2.x). > 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 There were already some ideas discussed at the amsterdam meeting. Stig suggested that PEAR would get a local dependency database which could be used for quick dependency resolution. > 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. Yes these are the limits of the PEAR installer atm. I personally bundle all PEAR packages with my applications. This seems to be the only way to really be sure things are working right. All the solutions mentioned in this thread are not ideal. However if you have an installer handle the updating of packages for the applications the main issue seems to be disk usage, which I find the smallest issue to accept. > 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. It is recommended that you keep dependencies as low as possible. So if all you use are very small portions of the code, then code duplication is recommended. > 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. I think subpackages are overkill. We should rather consider splitting up packages, even if that means a package is useless without another one. Like the phpDocumentor pdf generator will probably be useless for any package but phpDocumentor. For example I am separating the schema manager from MDB (however the schema manager will not require MDB in my case, but the default readers and writers will, so there will be an option dependency on MDB) > 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 :). Yup a seperate application.xml seems to bet he way to go. > 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. Yeah we should definately start to talk about it. However remember that currently we have a lot of discussions going on. Hopefully everybody can discuss all of the things we have open without confusing the threads or who said what when where :-) Regards, Lukas