Add PEP 262, "A Database of Installed Python Packages". This is the same

version that's just been sent to the Distutils SIG.

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
 

pep-0262.txt

@@ -0,0 +1,152 @@
+PEP: 262
+Title: A Database of Installed Python Packages
+Version: $Revision$
+Author: A.M. Kuchling <akuchlin@mems-exchange.org>
+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
+    <prefix>/lib/python<version>/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<version>?'  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: