Re: bundles

Hi Greg, This is a good summary of the difficulties bundles present. IMHO it's one of those ideas that sound great at first, but when you start picking it apart, the complexity and overall cost just outweighs the benefits. But what are we trying to fix here? I have to admit I don't really see a problem that needs fixing :) Do people *need* to be able to choose which parts of a package/bundle they want to install, and won't optional dependencies solve this? We're talking about a good amount of complexity for (IMHO) questionable gain. So let's go back to "as simple as possible, but no simpler": * bundles are just packages following a naming scheme, and contain any packages they depend on * as such, "bundle" becomes just a concept, the installer treats a bundle as any other package * added system complexity: zilch This doesn't deal with uninstalling the package as a unit, but that could be done in a simple way too, by adding a "installed-as-part-of" field to the package registry. We'd still have to deal with some hairy upgrade/uninstall semantics, but it should be doable, and it could even be easy to understand for maintainers and users :) - Stig On Wed, 2004-09-15 at 03:22, Greg Beaver wrote: > [snip] > I'll try to present both options with their advantages and drawbacks > like a good non-partisan :). > > A better example than DB is phpDocumentor. > > My proposal: > > phpDocumentor would have bundles for each of the templates, as well as > groups of templates, for converters and default templates, converters > with no templates. > > you can install the packages manually: > > $ pear install PhpDocumentor_HTMLSmartyConverter > PhpDocumentor_HTMLSmartyConverter_template_default > PhpDocumentor_HTMLSmartyConverter_template_PHP > PhpDocumentor_CHMConverter PhpDocumentor_CHMConverter_template_default > Core@PhpDocumentor (let's try an alternative syntax to spice things up) > > or with a bundle > > $ pear install SmartyAndCHM@PhpDocumentor > > and you can uninstall using the packages: > > $ pear uninstall PhpDocumentor_HTMLSmartyConverter > PhpDocumentor_HTMLSmartyConverter_template_default > PhpDocumentor_HTMLSmartyConverter_template_PHP > PhpDocumentor_CHMConverter PhpDocumentor_CHMConverter_template_default > PhpDocumentor > > or with a bundle > > $ pear uninstall default@PhpDocumentor > > advantages > ---------- > 1) it can be handled easily on the client-side with existing package.xml > parsers > 2) linking bundles to the packages and the releases that they work for > is straightforward and easy both from a client-side and a server-side > perspective > 3) versioning of package releases is directly linked to bundled > packages' versions through the "recommended" attribute in package.xml > 2.0 dependencies > 4) commands for installation are very similar to the way they work now > > disadvantages > ------------- > 1) it requires some magic perl-style punctuation (the bundle separator) > 2) uninstallation still has some serious issues to work out, mainly if > > $ pear install DB > > installs all the packages in the default bundle, should > > $ pear uninstall DB > > uninstall them, or is this too much magic? I tend to think that it > should uninstall them, but perhaps there should also be an "uninstall" > bundle. In any case, this is truly a complex issue. > 3) bundles and dependencies are pretty similar in concept, and so you > can't use --onlyreqdeps or --alldeps with a bundle. The bundle should > instead contain everything that should be installed. > 4) can you add a dependency on a bundle? The question is difficult to > answer, but if the answer is "no" this requires some redundancy in the > dependencies, and that always opens up room for installation errors that > must be tested for. > > Empty packages proposal: > > Same thing about installing the packages individually as my idea. > > empty packages that would need to be defined in order to fit this mold: > phpDocumentor_Core > phpDocumentor_HTMLSmartyConverter > phpDocumentor_HTMLFramesConverter > phpDocumentor_CHMdefaultConverter > phpDocumentor_HTMLSmartyConverter_template_default > etc. > > The problem is that I would also want packages named > "PhpDocumentor_HTMLSmartyConverter" and so instead I would need to name > the empty packages something else - double the packages. > > So, in order for this to work, empty packages would need to be something > different from packages, bundles will suffice as a name. They would > need to be installable with a custom command to work as a namespace > differentiator > > $ pear install-bundle PhpDocumentor_HTMLSmartyConverter > > uninstallation would also need a special command > > $ pear uninstall-bundle PhpDocumentor_HTMLSmartyConverter > > advantages > ---------- > 1) no magic perl-like bundle separator is needed > 2) separation of bundle logic allows bundles that have nothing to do > with any particular package like the PFC bundle in go-pear > 3) bundles can be prepared by non-developers > 4) very similar to the way things work now in package.xml, slightly less > learning curve will be necessary for developers packaging their bundles. > > disadvantages > ------------- > 1) linking of bundle versions to package release versions becomes more > difficult > 2) namespace issues: bundles and packages probably need separate > namespaces, which means adding commands to the installer > 3) how do you handle dependencies in an external bundle if a package > inside the bundle upgrades and adds a required dep? Can you depend on a > bundle in package.xml? > 4) a new bundle.xml would need to be created and parsed. > 5) additional pearweb commands to retrieve bundles will be needed > > pearweb will need a non-trivial update to support either case. > > So, to the best of my ability for tonight, these are the differences in > the proposals. > > From a coding-the-installer perspective, I'd say the largest difference > is the coupling of bundles to packages. If we were to go with the > separate bundles, it would eliminate the possibility of specifying > official bundles in a package.xml as anything more than informational, > all of this would have to be on the package's webpage, and not directly > retrievable through the installer. > > I think my primary resistance stems from the increased administrative > complexity this would introduce. If slightly more complex code causes > simpler administration, I think it will be more likely to succeed than > the other option. However, I'm not sure that either method is more > complex from a coding perspective because of the drawbacks in each. > > A particularly thorny issue is uninstallation - I think users might be a > little miffed if they see > > $ pear install DB > install of DB OK > install of DB_mysql OK > ... > $ pear uninstall DB > cannot uninstall DB, DB_mysql, DB_mssql,... depend on DB > > unless we provide > > $ pear uninstall DB > cannot uninstall DB, DB_mysql, DB_mssql,... depend on DB > use "pear uninstall alldrivers@DB" to uninstall all drivers > > or, some default uninstallation bundle, but then we're getting into more > complexity than seems necessary. > > perhaps adding an attribute to bundle if it can be used as an > uninstallation shortcut and a little hint > > <bundle name="alldrivers" hint="all drivers" > uninstallable="yes"> > > $ pear uninstall DB > cannot uninstall DB, DB_mysql, DB_mssql,... depend on DB > use "pear uninstall alldrivers@DB" to uninstall all drivers > > In any case, there's the reasoning I've been thinking. Also, I was > thinking that the actual implementation of bundles might be postponed > until 2.0, but the ideas decided on enough in advance to let them simmer > until something really tasty comes out. > > That is, unless it turns out to be really simple to implement at > pearweb, because client-side implementation is really easy and > remarkably simple, at least of the proposal I'm suggesting. I haven't > tried implementing the other one, it seemed more complex to me on the > client-side. > > Greg