Splitting of Structures_DataGrid into subpackages?

Olivier Guilyardi wrote:

> IMO we don't need real subpackages, just artificial
subcategories on the
> web site, to make browsing packages comfortable. I
agree that these 17
> new packages (and new drivers that users will submit)
are going to flood
> the web interface.
> 
> One may argue that package.xml could be where to
configure such
> subcategorization... But some fields on the "New
package" form at
> pear.php.net could also do the trick.

package.xml is used for installation only.  In other words,
this only
affects the way people view the packages.  As such, this
information
belongs solely on the server in REST and in the
categorization.
Sub-categories would be an easy way to support this, but
then again,
someone would need to code the actual support, as always


From an installation perspective, package.xml already has
full support
for sub-packages through optional package groups.  For
instance, if you
define a group named "all" that contains all the
drivers, users can
install all of them with:

pear install Structures_DataGrid#all

Even more important, users can remove them all at once with:

pear uninstall Structures_DataGrid#all

Note that this will work even if only 1 driver is installed,
as it will
simply pass over packages that are not installed.

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Greg Beaver wrote:
>>From an installation perspective, package.xml
already has full support
> for sub-packages through optional package groups.  For
instance, if you
> define a group named "all" that contains
all the drivers, users can
> install all of them with:

In package.xml, should we use <group> or
<subpackage> ?

--
   og

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php