Re: package validation (was Re: [PEAR-QA] Re: PHP_Beautifier-0.0.6.1

Greg Beaver wrote:

Tomas V.V.Cox wrote:

The pear installer needs urgently, apart of a decent DTD validation, one of these two: a) Remove any PEAR coding standar rule that is hardcoded today. b) Provide something like a plug-in system which validates the package.xml fields according to the rules of each "channel" developers.

You really need to check out the code in PEAR-1.4.0dev5.tgz, in particular PEAR_PackageFile and PEAR_ChannelFile classes. A package name validation regex is already in channel.xml and is fully supported by the installer.

IMHO this is not the place, see my opinions below.

Far better than doing this in pre- and post- scripts is to leverage the existing power of polymorphism. Simply allow users to extend PEAR_PackageFile, and redefine the validation of package version. Most of this stuff should be server-side, and not in the pear packager, as things like this tend to change as the political decisions change.

One idea could be. A new <php_dir>/PEAR/validations/ dir. Inside it there would be one <channel> dir where validations stands. Each channel team writes a package called for example: ChannelValidation_<channel name>, which would contain any number of installable php files at <php_dir>/PEAR/validations/<channel name>. When developers do a "pear package" those validations are executed. The same goes for the website, prevalidating a package before accepting it. Not even this, each developer could code it's own validation rules for his packages, just trowing a file under <php_dir>/PEAR/validations/<channel name>. His validation rules could just include at top: "if ($package['name'] != 'DB') skiptest();" or "if (!$package->isMaintainer('cellog')".

The only other alternative is to add a field to the channel.xml for describing version validation, which would be far more complex than I'm willing to deal with.

I could take care on this. What would help a lot, is to split the PEAR package in two: one for users and one for developers. The first would only give minimal commands, classes and deps, for just do basic operations on package maintence. The second one, could have unlimited deps on other packages as it supposed that only packagers should use it. A negative side effect of this split, is that we'd loose some pre-validations at install time. That could be solved if we start signing our packages: # pear help sign pearcmd.php sign <package-file> Signs a package distribution (.tar or .tgz) file with GnuPG. Just an idea. Tomas V.V.Cox