Re: bundles

Stig S. Bakken wrote:

Sorry for making that assumption, read up on pear-core cvs mails now, glad to hear sub-packages are no longer a topic :)

It's no problem, I don't think it will be necessary to make them a topic with the system I've been working on. This is, by the way, an outcome of a series of discussions on subpackages that Tomas and I had on IRC many months ago. He was excited about bundles, and convinced me at the time that this was more the way to go. It just happens that recently I've reached a point in channels development where it would be a good idea to plan for this in package.xml 2.0 if it's ever going to happen. Right now, I've got placeholders in the (uncommitted) code for pearweb that would eventually be filled with code. The main thing is I'd like to get basic details worked out enough so that the initial coding isn't too headachey.

I agree with you on this: enough complexity to get the job done. The installed could have been a lot cleaner and St. Peter will probably give me some heat for PEAR_Common when that time comes. But that was the tradeoff I had to make to get PEAR up and running, fully aware that the installer needed a rewrite down the road.

PEAR_Common does just fine. I wouldn't worry about that one :). It has taken me ages to get the PEAR_PackageFile class healthy enough to consider it useful, I can't imagine trying to do that without the infrastructure already in place. No undeserved self-flagellation!

The brave coder in consideration is the one who needs to write and maintain/understand the code to _resolve_ four-dimensional dependencies, especially when one of the dimensions (platform) is non-linear. But this was really a comment about adding sub-packages.

gotcha.

This requires the other packages to be a part of the tarball, no?

Just an idea, makes "bundles" becomes more like the name suggest. But having packages with only dependencies works too.

I see. Yes, I was planning to implement this style of bundle as well, without calling it a bundle. My idea for this was exactly this style, except instead of placing all the dependency information in the <file> tag, it would be done in multiple release tags, but that is a discussion for another thread :).

Upgrading becomes hard to implement, if not impossible, and each package has its own copy of anything it uses. This is one way of doing things, but it is the way of doing things *before* PEAR existed, one that makes fixing bugs and maintaining separate releases a living hell.

[I do have a touch of the overly dramatic in me, don't I ;]

I should have elaborated more. The purpose of including actual packages is _only_ convenience / bootstrapping. For example, PHP releases could contain a single bundle (PFC or whatever), and the install would still do the same thing as today. The difference is that there is only _one_ package(bundle) to deal with. Not including the packages (but having only a list of dependencies) would be cleaner. Both would work; embedding the required packages is very useful for magazine CD-ROMs etc. Just throwing the idea out.

right, I agree 100% Both will be useful to different parties.

FWIW, CPAN has had bundles containing other packages for a long time, and seem to be moving more towards that approach.

good to know this when developing as well.

The ONLY reason I've been devoting time to the installer is to remove that living hell from the future. I am not interested at all in easy to implement. I am interested in three things: 1) easy to use 2) easy to maintain 3) easy to extend not necessarily in that order. They are wholesale opposites of "easy to implement" in more than half the specific projects I have coded, as this usually implies the least thought-out design.

I have a feeling you have been over-exposed to some old pear-core code committed by yours truly :)

Honestly, I was thinking more about my early attempts to code a "simple" database backend for my quartet's website :). It still sends shivers down my spine and food up my esophagus thinking about how "simple" it was to maintain this code.

Precisely - subpackages exist today, independent of the installer. I'm not talking about adding subpackages (DB_DataObject_FormBuilder could be considered a subpackage of both DB_DataObject and HTML_QuickForm, no? HTML_QuickForm_Controller is a pure subpackage of HTML_QuickForm).

You could get away with that, but the definition it too vague and certainly not deterministic. But it doesn't matter...

:) This is why I'm happy - the bundles implementation I'm talking about doesn't require any definition of what a subpackage is, and doesn't care.

So if "pear install DB" will work as it always has, how does your bundling proposal differ from having a package with packages and dependencies?

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