Re: question about PEAR vs. Zzoss installer

On 16 Aug 2003 at 18:41, Greg Beaver wrote: > Stefan Neufeind wrote: > > >On 16 Aug 2003 at 15:14, Greg Beaver wrote: > > > >>Stefan Neufeind wrote: > >> [...] > >>This should only affect the download stage of installation - once a > >>package is installed, it is registered using the package.xml. There > >>is a new problem that would be introduced, that of namespace. In > >>other words, someone might release a package called "Config" or > >>"XML_Util" that has nothing to do with PEAR. In this case, the > >>installer would get confused about version numbering, not realizing > >>that it's a different package entirely. > > > >Well in Java afaik they handle namespaces by including domainnames to > > indicate the namespace. If I remember correctly > > > > class com.sun.java.Class1 > > > >or something (read from left to right). This does not necessarily be > >the url under which the package can be found but this is just a > >solution to ensure that it's unique. Maybe we could implement a > >similar namespace for "pear.php.net"? Having just PEAR::Package would > > also be okay - but what if more people use it and e.g. many people > >are named "Mueller" or similar as surname. Then Mueller::Package > >wouldn't be unique any longer. > > > > > The only drawback to this is that a registry of namespace => package > prefix would be required, which I think is not likely to happen unless > pear-group likes the idea, and someone jumps forward to maintain it. I don't think a real "registry" is needed. Naming a namespace "pear.php.net" would automatically make all packages fall into that namespace. And if others bring up packages (Horde etc.) they also own their domain and can uniquely issue packages with THEIR namespace. So there shouldn't be any conflicts. We just have to see how these problems can be technically solved and what the others think about the idea of such a feature. > >>I agree that packages should not have dependencies outside of PEAR. > >>The issue comes when you have applications. HTML_SetupWizard, for > >>example, depends on several packages, and can be used as a > >>standalone application with some programmatic configuration. > >>phpDocumentor has several converters, with the possibility of adding > >>others. I don't think it's a good idea to clutter the pear package > >>space with new packages just for phpDocumentor converters, when they > >>can be hosted off of phpdoc.org. It would basically be a first step > >>towards implementing sub-packages - packages that cannot work > >>without the application they were designed for, but are modular > >>components that have a different stability level from the core of an > >>application, and so should be released separately as well as in a > >>bundle. I hope this makes sense, that was an awfully long sentence > >>:). > > > >We were talking about dependencies, right? So there should be nothing > > external that packages depend on. Greg, from your experience, is > >this > > > Imagine this situation: someone wants to write an application based on > a few PEAR packages and a few Horde packages that work together, and > distribute it within a company. Currently, they cannot use the PEAR > installer. Again, I'm not talking about packages, I'm talking about > standalone applications that use packages, a very different situation. Well I only proposed that packages *inside* pear *should* not have external deps. In all other cases (custom packages, applications, ...) I personally have no problem at all using the installer this way. > I know PEAR wishes to keep PEAR pure, but the real world of open > source is that you mix and match the best of anything and everything > to make things work. phpDocumentor uses a PDF generation package that > is based on sourceforge, PEAR's HTML_TreeMenu, Smarty, and so on. > It's silly for us to bundle all of these applications when they may > already be installed. This, I imagine, is why PEAR was started in the > first place? Opening up this aspect of applications (NOT packages - > let's be clear here), will help to turn around the common view of PEAR > as a closed society, and help people realize it's actually usable for > almost any situation. > > <can contents="worms" action="open">In other words, I think the > greatest strength of PEAR is its ability to handle dependencies, and > to allow them. Greater dependency = leaner install, easier > maintenance (if there's a bug, you know how to fix it for every > application - pear upgrade packagename), and so on. For applications, > the ability to support dependencies is essential, and I would suggest > that the ability to install and configure packages both within and > outside of PEAR might be the quickest way to ensure universal usage of > PEAR by PHP users.</can> > > I'm not suggesting a big change here like some of my other posts, but > I did want to explain my motivations. Guess they were made clear and guess / hope we got the intention. This is generally a good idea in my eyes. Just let's see which ways there are to make it come true ... Comments from a installer-dev maybe?!? > >This seems a good thought to me. And although it might introduce a > >lot of discussion and work combined I believe it's worth the effort. > > > Agreed Fine :-) So we are the first two that agreed on the general topic. Maybe someone could come up with technical background and concrete proposals? Stefan