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