PyPPM/[Distutils] Package DB: strawman PEP

[Dan Milgram]

I'd like to take the opportunity to discuss some of the work done at
ActiveState that is pertinent to the discussion at hand. While I suspect
most people subscribed to this list are already familiar, I'll assume
nothing for clarity sake.

In its current form a repository is accessible which allows for easy
installation of python packages
(see http://www.ActiveState.com/PPMPackages/PyPPM/2.1/ )

Our equivalent of PKG-INFO is a PPD file
type that stores data in an XML format. A PPD file describes a PyPPM
package which is a built distutils package in an archive format (.tar.gz
or .zip depending on platform). While currently packages can only be
downloaded, a demo will be presented at the upcoming O'Reilly open source
conference of a repository which exposes functionality discussed in the
catalog SIG.

In addition to the standard metadata  handled by distutils
(author,author_email,license, etc.) a PPD can contain
the following elements:

INSTALL - an installation string for installing packages distributed in a
non-distutils binary distribution format (eg. RPM, setup.exe etc.)

DEPENDENCIES - handles dependencies (eg. PIL-Graph's dependence on PIL)

IMPLEMENTATION - an implementation may contain a PYTHONCORE,
ARCHITECTURE, and OS elements, in addition to a CODEBASE element. The
CODEBASE element defines the URL of the actual package, while the others
define the relevant implementation characteristics of said package

When a PyPPM package is installed on a client machine package instance
data is stored in an XML database. In its current form, the database
stores configuration information for the PyPPM client (eg. a repository
location is specified), and descriptions of packages installed
(essentially all the information contained in a PPD minus implementation
data for other platforms).

Additionally storing each file installed within a package would allow for
provision of the functionality suggested (and sorely needed :)) in
Andrew's PEP. I would argue that adopting an XML format would be
beneficial, unless performance is deemed a major issue, however I suspect
people don't want to rehash PPD vs. PKG-INFO type arguments

>From a compatibility standpoint it would be nice if the database info is
not an addon to distutils through another package manager, but intrinsic
to it.

Finally some random thoughts:
- It would be great if we could get some momentum behind PEP 250 - this
will simplify the task of adopting the Package DB PEP

- it would be nice if we could remove potential metadata conflict issues
that could exist, as identical metadata fields can be stored within the
setup.py and the PKG_INFO file (what's deemed canonical by the database?)

- the core python version should be stored for a given package in the
database, so that a package manager can "do the right thing" when a python
distribution is upgraded. Arguably, functionality for maintaining database
consistency between unpure python packages and a given python distribution
could be the domain of the database functionality

Regards,
Dan

-- 
Dan Milgram/ActiveState Developer
New! ASPN - ActiveState Programmer Network
Essential programming tools and information
http://www.ActiveState.com/ASPN