diff --git a/pep-0000.txt b/pep-0000.txt index 45d300cf2..dfc23cef9 100644 --- a/pep-0000.txt +++ b/pep-0000.txt @@ -64,6 +64,7 @@ Index by Category S 258 pep-0258.txt DPS Generic Implementation Details Goodger S 260 pep-0260.txt Simplify xrange() van Rossum S 261 pep-0261.txt Support for "wide" Unicode characters Prescod + S 262 pep-0262.txt Database of Installed Python Packages Kuchling Py-in-the-sky PEPs (not ready; may become active yet) @@ -196,6 +197,7 @@ Numerical Index SR 259 pep-0259.txt Omit printing newline after newline van Rossum S 260 pep-0260.txt Simplify xrange() van Rossum S 261 pep-0261.txt Support for "wide" Unicode characters Prescod + S 262 pep-0262.txt Database of Installed Python Packages Kuchling Key diff --git a/pep-0262.txt b/pep-0262.txt new file mode 100644 index 000000000..4463914fd --- /dev/null +++ b/pep-0262.txt @@ -0,0 +1,152 @@ +PEP: 262 +Title: A Database of Installed Python Packages +Version: $Revision$ +Author: A.M. Kuchling +Type: Standards Track +Created: 08-Jul-2001 +Status: Draft +Post-History: + +Introduction + + This PEP describes a format for a database of Python packages + installed on a system. + + +Requirements + + We need a way to figure out what packages, and what versions of + those packages, are installed on a system. We want to provide + features similar to CPAN, APT, or RPM. Required use cases that + should be supported are: + + * Is package X on a system? + * What version of package X is installed? + * Where can the new version of package X be found? + XXX Does this mean "a home page where the user can go and + find a download link", or "a place where a program can find + the newest version?" Perhaps both... + * What files did package X put on my system? + * What package did the file x/y/z.py come from? + * Has anyone modified x/y/z.py locally? + + +Database Location + + The database lives in a bunch of files under + /lib/python/install/. This location will be + called INSTALLDB through the remainder of this PEP. + + XXX is that a good location? What effect does platform-dependent code + vs. platform-independent code have on this? + + The structure of the database is deliberately kept simple; each + file in this directory or its subdirectories (if any) describes a + single package. + + The rationale for scanning subdirectories is that we can move to a + directory-based indexing scheme if the package directory contains + too many entries. That is, instead of INSTALLDB/Numeric, we + could switch to INSTALLDB/N/Nu/Numeric or some similar scheme. + + XXX how much do we care about performance? Do we really need to + use an anydbm file or something similar? + + XXX is the actual filename important? Let's say the installation + data for PIL is in the file INSTALLDB/Numeric. Is this OK? When + we want to figure out if Numeric is installed, do we want to open + a single file, or have to scan them all? Note that for + human-interface purposes, we'll often have to scan all the + packages anyway, for a case-insensitive or keyword search. + + +Database Contents + + Each file in INSTALLDB or its subdirectories describes a single + package, and has the following contents: + + An initial line listing the sections in this file, separated + by whitespace. Currently this will always be 'PKG-INFO + FILES'. This is for future-proofing; if we add a new section, + for example to list documentation files, then we'd add a DOCS + section and list it in the contents. Sections are always + separated by blank lines. XXX too simple? + + [PKG-INFO section] An initial set of RFC-822 headers + containing the package information for a file, as described in + PEP 241, "Metadata for Python Software Packages". + + A blank line indicating the end of the PKG-INFO section. + + An entry for each file installed by the package. + XXX Are .pyc and .pyo files in this list? What about compiled + .so files? AMK thinks "no" and "yes", respectively. + + Each file's entry is a single tab-delimited line that contains the + following fields: + XXX should each file entry be all on one line and + tab-delimited? More RFC-822 headers? AMK thinks tab-delimited + seems sufficent. + + * The file's size + + * XXX do we need to store permissions? The owner/group? + + * An MD5 digest of the file, written in hex. (XXX All 16 + bytes of the digest seems unnecessary; first 8 bytes only, + maybe? Is a zlib.crc32() hash sufficient?) + + * The file's full path, as installed on the system. (XXX + should it be relative to sys.prefix, or sys.prefix + + '/lib/python?' If so, full paths are still needed; + consider a package that installs a startup script such as + /etc/init.d/zope) + + * XXX some sort of type indicator, to indicate whether this is + a Python module, binary module, documentation file, config + file? Do we need this? + + A package that uses the Distutils for installation will + automatically update the database. Packages that roll their own + installation + + 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?) + + +Deliverables + + Patches to the Distutils that 1) implement a InstallationDatabase + class, 2) Update the database when a new package is installed. 3) + a simple package management tool, features to be added to this + PEP. (Or a separate PEP?) + + +References + + [1] Michael Muller's patch (posted to the Distutils-SIG around 28 + Dec 1999) generates a list of installed files. + + +Acknowledgements + + Ideas for this PEP originally came from postings by Greg Ward, + Fred Drake, Mats Wichmann, and others. + + Many changes and rewrites to this document were suggested by the + readers of the Distutils SIG. + + +Copyright + + This document has been placed in the public domain. + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +End: