Re: bundles

Lukas Smith wrote:

I presume Greg expects developers to chop their pckages into sensible subpackages and not giving the users the ability to select specific files.

right

Let me brainstorm some related topics. Currently we have alot of packages that support different backends, optional security improvements etc. Especially for the different (database) backends alot of packages already support 3 difference abstraction layers and usually users only want one. So for that users will eventually be able to select what they want at install time. Now the question is if we want to enable users to set those selections globally similar to how gentoo allows you to. So setting the global option "DB" would set the "only install the DB backend if relevant" for every package being installed.

This seems a bit too magical to me. There are two kinds of PEAR users: - shared hosts - single private installations Shared hosts will always want to install all available options, in order to support every possible user on their system. Single users will always be able to fine-tune their installations, and so having explicit choices is much better.

Thinking about it I now understand why Greg is using the # for both bundles and subpackaging (for lack of a better term). Essentially the # syntax is about being able to pass options for a specific package within all of the package that were listed in the pear command (Greg actually stated this, so I am just trying to find my own words for what he was saying .. I hope).

Not just options, but installation choices. Instead of forcing a user to figure out which supporting packages are needed in order to get a package that will do what is needed, the user can simply think "I want a package that will give me authorization storage using DB as a backend and I want to use mysql" $ pear install Auth#DBbackend DB#mysql [It is very important to note that I am only using "#" as the separator out of consistency, if enough people choose a particular option as being better, that will be used.] This should be contrasted to: $ pear install Auth_DBBackend DB_mysqldriver which is what Cipriano is suggesting. This requires a huge amount of effort on the pearweb backend, and is very inflexible (the bundles can't have the same names as subpackages, for instance). Once an empty package is created, the name is set forever, and a subpackage cannot use it because of BC. It's literally like using a global variable for what should be a class property in PHP. Linking empty packages to existing packages is very difficult, and listing them on the package page will require more than extensive changes to pearweb. The solution I'm proposing is far more robust when we're talking about packages directly related and necessary for the operation of a package, but only for particular problems (optional deps, remember). In addition, you still need to specify these empty packages in the package.xml for them to be of any use to end-users. Instead of: <bundle name="DBBackend"> <package name="DB" recommended="1.7.0"/> <package name="DB_DataObject" recommended="1.2.3"/> </bundle the user now sees <bundle package=Auth_DBBackend version="1.2"/> This means that in order to find out what is in the bundle, the user has to go online and look the package up. In addition, if the bundle version is not explicitly specified in the <bundle> tag, the user cannot count on what will be installed, but will have to guess. All in all, I don't see this as the best solution for the reasons above. However, "empty packages" are exactly what I mean by the collections of unrelated packages. However, they would NOT be called packages, but bundles (or whatever we come up with) Remember, these are two different problems: 1) creating sets of packages that solve a subset of the problems that a package solves and are required to solve those problems, but not required for other subsets of problems (optional deps serve this purpose sometimes in the existing PEAR) 2) creating sets of unrelated packages that can be useful together because of a shared characteristic (PFC packages are all certified to be kickass and stable, for instance) Greg