[Distutils] Package DB: strawman PEP

[Mark W. Alexander]

On Sun, 8 Jul 2001, Andrew Kuchling wrote:

> It seems time to bite the bullet and actually begin designing and
> implementing a database of installed packages.  As a strawman to get a
> focused discussion started, here's a draft of a PEP, with lots of
> XXX's in it.  Followups to the Distutils SIG, please.

I'm confused. Why? What does this give us that native package managers
don't. How is it going to keep synchronized with package manager?

If I understand correctly, most of what's desired here could be
accomplished by including the PEP 241 metadata in the module in a
manner that could be inspected upon import. Distutils could even go so
far as to create a PKG_INFO subpackage ao you could import
mymodule.PKG_INFO. If is succeeds, it's a distutils created module and
contains all PEP241 required information.

>     XXX what's the relationship between this database and the RPM or
>     DPKG database?  I'm tempted to make the Python database completely
>     optional; a distributor can preserve the interface of the package
>     management tool and replace it with their own wrapper on top of
>     their own package manager.  (XXX but how would the Distutils know
>     that, and not bother to update the Python database?)

If it's optional, then maybe, sometimes, you might have the
information that it could have provided you. In the long run, your
better off making it simple and painless to create packages for the
native system's package manager. Then people need look only one place
for everything. (I still like the idea of the 241 metadata being
accessible in the module itself. It makes it more convenient for
module authors to query information specific to distutils module
relationships.)

Mark