Re: possible solution to bundles vs. bundles [sleeping does help!]

A little off topic, to be honest, I'm not 100% sure, I have a real need the bundling stuff, but the making deps work with fixed urls would help no end: eg. <dep type="pkg" rel="has" name="Foo" src="http://www.akbkhome.com/.......mypackage.tgz"/> This may remove the necessity for pearballs..., as I'm unlikely to set up a channel server just for a few packages. Regards Alan Greg Beaver wrote:

Hi, I just woke up from a much-needed nap (gotta love regressing to childhood, eh?) and in a flash had an idea that possibly solves the problems with bundles. The in-package bundles that I have been speaking of are really dependency groups, and as such they should only provide shortcuts similar to --alldeps and --onlyreqdeps, but more structural and less guess-worky. Limiting these in-package bundles to dependencies should solve the entire issue, as all of the ambiguity over "what the hell is it" should be gone. :) The out-package bundles are the "empty packages" So, the way I would implement these two separate issues is as follows: dependency groups ----------------- dependency groups are already partially implemented in package.xml 1.0, but in a haphazard manner, using the "optional" attribute. This is in the "optional" group of dependencies: <dep type="pkg" rel="has" name="Foo" optional="yes"/> This is in the "required" group of dependencies: <dep type="pkg" rel="has" name="Foo" optional="no"/> Now, what I would do is revise this device as follows: 1) take the package.xml concept of dependencies, and allow them to be grouped. Dependencies are naturally grouped in the real world, this would only reflect that grouping in package.xml to help users decide which optional dependencies would become required dependencies by the use of an optional feature. In other words, if the PDF Converter is an optional dependency of phpDocumentor, as it is not needed to generate html documents, then a user who wishes to generate PDF documentation requires the PDF Converter and at least 1 PDF template. The PDF feature is optional, but when you want to use it, you require a set of packages in order to use it. Here is a sample hypothetical session: $ pear list-dependencies PhpDocumentor REQUIRED: --------- pear::PEAR > 1.4.0, recommended 1.4.3 pear::Log > 1.7.0, recommended 1.7.0 OPTIONAL GROUPS: ---------------- default - all converters and templates PDF - PDF Converter and template core - barebones, no converters or templates ... note: help list-dependencies for more info $ pear help list-dependencies Lists dependencies. To list the dependencies in an optional dependency group, use Package#Group as in PEAR#developer will list the optional dependencies in the developer dependency group of the PEAR package. $ pear list-dependencies PhpDocumentor#PDF phpdocumentor::PDFConverter, recommended 1.0.0 phpdocumentor::PDFConverter_template_default, recommended 1.0.0 $ pear install PhpDocumentor#PDF install OK pear::PhpDocumentor install OK phpdocumentor::PDFConverter install OK phpdocumentor::PDFConverter_template_default Instead of having to guess as to which optional dependency actually is required in order to use the pdf converter, the user only need to think "I want PDF" and they will get it By default, all converters, templates and bells and whistles are installed, maintaining BC. These same groups can be used to uninstall optional dependencies. Required dependencies are grouped separately. These are dependencies that *must* be installed for any component, optional or required, to work. here's the internals of the package.xml: <php> <!-- release tag for php packages (packages written in php) --> <dependencies> <required> <!-- these will always be installed, or fail installation --> <pearinstaller min="1.4.0" recommended="1.4.3"/> <package name="Log" channel="pear" min="1.7.0" recommended = "1.7.0"/> </required> <group name="default" hint="all converters and templates"> ... </group> <group name="pdf" hint="PDF converter and template"/> <package name="PDFConverter" channel="phpdocumentor" recommended="1.0.0"/> <package name="PDFConverter_template_default" channel="phpdocumentor" recommended="1.0.0"/> </group> <group name="core" hint="barebones, no converters or templates"> <!-- empty, to install no optional deps at all --> </group> </dependencies> <php> bundles ------- bundles are *not* generic like packages, these are either: - one-time .tgzs created with a package.xml and internal .tgzs - a package.xml with a required dependency group that downloads the packages. - the package.xml release section will be specially named "bundle" so that no need for bundle.xml is created, and no confusion with existing php code, extension source and extension binary package types exists. <filelist> <dir name="/"> <file role="package" name="Log-1.7.0.tgz"/> </dir> </filelist> ... <bundle> <!-- release tag for bundles of other packages --> <dependencies> <required> <php min="4.2.0" max="5.0.0" recommended="4.3.8"/> <package name="XML_Util" recommended="1.3.0"/> </required> </dependencies> </bundle> <bundle> <dependencies> <required> <php min="5.0.0" max="6.0.0" recommended="5.1.0"/> <package name="XML_Util2" min="2.0.0" recommended="2.0.2"/> </required> </dependencies> </bundle> This will solve the pearweb dilemma, as no fake packages will be created to house these bundle packages, and no registry of installed bundles will be made, only of the packages they contain. It also allows creation of differing bundles depending on php version or operating system, or any other dependency, but that feature is negotiable as it might be a bit too complex :). Greg