Re: bundles

Daniel Convissor wrote:

for category #2 is a different animal, although it could be used, for instance, to distribute a complete application(or package) with all of its dependencies in a single tarball

Rather than taring them all together, I was more thinking that the channel server would have a "bundle" database saying which files get shipped for a given "bundle."

This would be the default case, I only meant to say that an obvious extension of this case would be that you could bundle the whole thing up into a single file, instead of requiring separate downloads. People who are used to downloading a whole application in one fell swoop will like this option, of course. I prefer the ability to download little chunks, myself, as long as I don't need to know the details.

I have great reservations about mixing installation of packages and bundles of the 2nd variety. I would prefer a totally separate command. pear install-bundle PFC pear download-bundle allPEAR

Sounds good. Though, as mentioned above, we'll need different terms for each type of "bundle."

Yes, I think you're right. Any suggestions? I literally couldn't care less as to what they are called, as long as everyone can agree on the implementation. I will either change the tagname in package.xml, or the install-bundle command. Simple enough :). Greg

$ pear install --alldeps DB#mysql WARNING: --alldeps and --onlyreqdeps are ignored when installing a bundle download of DB OK download of DB_mysql OK install OK [abbreviated, of course]

I trust that's only a quick example that hasn't been thought through all the way. The notion of only being able to install only certain scripts from a package is going to lead to a gigantic mess. I don't think that's your intention, but I'm asking just to make sure.

I did make an assumption, and skipped a logical step in my thinking-out-loud email. Right now, DB's package.xml consists of DB.php and a whole bunch of drivers. Most users use at most 1 driver, obviously. The idea here was that each driver would become a separate package - which would also allow all of the stability information you have in that text file to become obsolete - each driver would function on its own terms. Warning flags go up here, I imagine :). "What about BC? Users expect the DB package to contain every driver and can't be expected to suddenly figure out the bundle they need to install!!" Fortunately, I thought of this one :). The saving idea is that each package has the option of defining a "default" bundle - this bundle would be installed by default when the user types: $ pear install DB and would include every driver's specifically recommended version, just as in the current package.xml. If no default bundle is present, then the only thing installed is the contents of the package.xml unless a bundle is explicitly asked for. The logical difference between the old DB package with every single driver in the same package.xml and the new DB package with every single driver in its own package would be zero, thanks to the "recommended" attribute - the exact version of drivers that you as the packager knows works with the existing DB.php will be installed. Of course, if any individual driver has bugs or adds a feature, it can be released independently of the DB package, with that little <compatibility> tag, and users can get a lower-bandwidth upgrade. In addition, the preferred_state could be honored on a much finer level (i.e., only install stable DB drivers, rather than install DB and scour the README to see what is stable). Of course, any package author that is uncomfortable with this need not do it, this is all entirely optional flexibility, but having it as an option allows extremely modularity without any concern for upgrades breaking things, as well as more accurate stability/state indicators (DB_fartsql might be devel while DB_mysql is stable). Greg