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

Tomas V.V.Cox wrote:

Greg Beaver wrote:

Tomas V.V.Cox wrote:

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>.

I dislike this solution - the simplest is to allow a custom PEAR_PackageFile object to be passed in. 1) this does not restrict the developer to place all validation classes in PEAR/validations 2) this does not restrict the developer to fit into any API except for PEAR_PackageFile. Anything else would create unneeded complexity. Any channel that needs complex validation could provide an extension to the PEAR package that is designed to do custom packaging and validation. Most channels will only need simple name validation, and forcing them to code this when they can pass in a simple regex in the channel.xml and leverage existing code doesn't make as much sense to me.

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')".

To me, this again sounds far too complex to be practical. In addition, a plugin system should not be file-based, but inheritance or object-based. Validation of the validation will be extremely difficult otherwise.

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.

This is good. All validation should occur at upload time except for basic package/channel validation. Moving the PEAR_Bundle, PEAR_Package and associated commands into a subpackage makes perfect sense to me. With the bundle idea I proposed, users could install $ pear install PEAR to get the basic PEAR and $ pear install PEAR/developer to get the package/bundle subpackages (another example of how the bundle idea would simplify things... :)

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.

Signing is a decent idea, if you can get GnuPG easily set up on non-unix OSes, but will not suffice as the only option until it is in wide practice. Currently, it doesn't seem to be in practice at all. We may want to investigate how linux is implementing signing of their cvs commits due to the SCO debacle. In any case, I think it will require far more modularization of PEAR before plugins are practical. The install class is still mostly legacy code. I hesitate to rewrite anything without substantial unit testing of every aspect of installation, otherwise verifying BC will be next to impossible. Fortunately, the day on which all installation code is truly unit tested is approaching. Right now, installation and download code is unit tested, and uninstall code is only partially unit tested. Greg