[Catalog-sig] PEP 242 & Distutils2

[Mark W. Alexander]

There's some issues with the PEP 242 metadata and the Distutils2 Wiki
discussion on REQUIRES and PROVIDES. Here's some thoughts, in the hope
that we can get these in sync.

First, I think it's very important to provide for a single source
package to produce multiple binary packages. Marc's Egenix package is
the example that comes to mind, but I also have some internal packages
with the same requirement. He's obviously jumped through a lot of loops.
Requiring extending 12 Distutils classes with 1600+ lines of code and
mix-ins is not exactly going to entice people to provide Distutils setup
scripts for their more complex projects.

The REQUIRES and PROVIDES metadata information is more properly
associated with binary packages than with source packages, and by
extension, looking through PEP 242 each of those items apply to binary
packages as well.

What I'd like to see in Distutils2 is a way to map package namespaces to
binary package targets.  he highest level namespace would be like Marc's
mxBase package, or -common in the .deb and .rpm worlds. A syntax needs
to be provided to specify what binary package lower level namespaces go
into.

Each binary package needs it's own set of Metadata. Fields that are not
specifically provided for a binary package would be inherited from the
global defaults; that of the source package. Again, using Egenix as an
example, mxDatetime's version is 2.0.3, mxTextTools is 2.1.0, and mxBase
is 2.0.4, etc. Any subpackage that does not provide it's own version
would inherit the source package's version.  This works especially well
for non-binary dependent information such as Author, home-page, email,
etc. By definition each binary package would be required to have it's
own name.

This provides for REQUIRES and PROVIDES to be specified at the binary
package level, which is where it makes the most sense from an end
user/sysadmin/installer level.

There's a monkey-wrench, however: Solaris. Solaris (SysV pkgtool*)
packages are restricted to a maximum of 9 characters. So for Solaris
users, the whole REQUIRES/PROVIDES mechanism falls apart because you
can't reference dependencies>9 characters. So in order to support
equivalent functionality on Solaris, PEP 242 needs to be extended to
include an official "abbreviated-name" that is <= 9 characters. (Or
worse, if there's another package tool out there with a smaller
name requirement then that would be the maximum abbreviated length.

As a sidebar, I assume the catalog will enforce unique names. Without
unique names, REQUIRES and PROVIDES are worthless. REQUIRES=X, where
there is more than one package X is less than helpful. The catalog
would also have to enforce uniqueness on the abbreviated name. Whether
names are acquired first-come, first-served or a registration process is
required I leave to the catalog people, but it needs to be enforced
somehow.

mwa

*Yes, I _do_ have a bdist_pkgtool (and one for HP) and I'm _trying_ to
get permission to contribute them...
--
Mark W. Alexander
slash at dotnetslash.net