[Distutils] Re: [Catalog-sig] PEP 241 draft

[Mark W. Alexander]

Is this referring to metadata or metadata, and to packages or to
packages? <G> We've had some discussions along these lines before....

First, there's the metadata that distutils needs to do it's basic
work, e.g. install stuff in the python tree. Then there's the 
metadata that's needed by the bdist_* commands in order to
produce a binary package. Now, there's the metadata for publishing
in the catalog.

Also, there's "package" as in "everything" this setup.py
produces, and "package" as in the binary packages produced
by the bdist_* commands as applied to this setup.py. For
example, Marc's mx extensions are (I think, haven't tried his
latest) in a single setup.py, yet could easily and properly
produce up to 5 binary packages, from the standpoint of a native
package manager.

I realize that the PEP (which stands for ...what?) part of the
thrust to get CyPhAN (probably not spelled right) capability,
but it would certainly benefit bdist authors if we included as
much metadata as they may require at the same time. To that
end, I just laid out (what I know of) the fields used by RPM,
DPKG, Solaris pkgtool, and HP's SD-UX. The union of all four
resulted in the following set (some of which you've got):

   Name
   Version
   Revision (packaging revision)
   Short Description
   Long Description
   Vendor/Author
   Group/Classification (This could be dropped and assumed to be
                         Languages/Python or whatever's approriate for
                         the platform)
   Copyright
   License (Not necessarily the same as copyright :()
   Packager
   Requires
   Supported Architectures  (I think your 'Platform' field would be
                             a combination of Arch/OS)
   Supported Operating System
   Control Scripts
      Pre-install
      Postinstall
      Pre-remove
      Postremove
   Files to install (and attributes)
   
These seem to be the minimum that a package manager will need to
make a binary package. Some managers can do more, given more
information, but those features should not be used. If they are,
"python setup.py bdist --format=stoopidmgr" would always work,
but "python setup.py bdist --format=smartdmgr" would fail. The
idea is to support additional binary package managers, without
having to change setup.py.

A couple more that are supported by 2 of them that I think might be
helpfull (e.g. optional?) are:

   Provides: What this package provides (virtual service)
   Conflicts: Packages that conflict with this

Keywords, though not required by package managers is a definite keeper.
I don't know if it needs any constraints though. Open source
"products" tend to be fairly realistic in their claims.

Including all this information provides (I think) most of what's
needed for the catalog as well as most of what's needed for packaging.
In order for the packaging support to be robust enough to
support sub-packages (multiple binary packages), the metadata
handler needs to allow multiple instances of most of these
fields. At the top level, there should be basically the list you
started with, since that information is constant for any sub-packages
as well. With the addition of "sub-package Name", the remainder
of the fields should be repeatable for as many sub-packages as I
need to support. (At least one would be required.) I think that
makes the RFC-822 header format a little restrictive, although I
don't know as if XML might be overkill. Maybe parseable python
dictionary style? e.g.

MyPackage={name='SuperPackage',  vendor="me", version="0.00001", ...
	{name='sub1', files=[....] }
	{name='sub2', files=[....] }
}

(Then again, isn't everything scheduled to be XML by this time
tommorrow anyway?)

The License field you put as a list of choices, which I think is
good for the catalog, but bad for producing binary packages. How
about a License-Style field for the catalog? The full license
should be included in either source or binary packages. Whatever
they're called, both need to be available.

Anyway, that's my $.02 plus a little more. I think this is a
good step towards a "standard" catalog system, and a great way
to promote additional bdist modules.

Mark Alexander
mwa@gate.net


On Tue, 13 Mar 2001, Andrew Kuchling wrote:

> Date: Tue, 13 Mar 2001 11:08:35 -0500
> From: Andrew Kuchling <akuchlin@mems-exchange.org>
> To: distutils-sig@python.org
> Cc: catalog-sig@python.org
> Followup-To: distutils-sig@python.org
> Subject: [Catalog-sig] PEP 241 draft
> 
> [Followups set to distutils-sig@python.org, since that's where most of
>  the posters are.]
> 
> I've checked in a first draft of PEP 241.  Here it is; please offer
> comments and changes.
> 
> PEP: 241
> Title: Metadata for Python Software Packages
> Version: $Revision: 1.1 $
> Author: A.M. Kuchling <amk1@bigfoot.com>
> Type: Standards Track
> Created: 12-Mar-2001
> Status: Draft
> Post-History:
> 
> Introduction

[snip, see the archives]