[Python-checkins] CVS: python/nondist/peps pep-0262.txt,1.1,1.2
A.M. Kuchling
akuchling@users.sourceforge.net
Mon, 25 Mar 2002 05:36:07 -0800
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv8912
Modified Files:
pep-0262.txt
Log Message:
Various changes inspired by Thomas Heller's c.l.p comments
Index: pep-0262.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0262.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** pep-0262.txt 9 Jul 2001 14:26:26 -0000 1.1
--- pep-0262.txt 25 Mar 2002 13:36:05 -0000 1.2
***************
*** 23,30 ****
* 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?
--- 23,30 ----
* Is package X on a system?
* What version of package X is installed?
! * Where can the new version of package X be found? (This can
! be defined as either "a home page where the user can go and
find a download link", or "a place where a program can find
! the newest version?" Both should probably be supported.)
* What files did package X put on my system?
* What package did the file x/y/z.py come from?
***************
*** 47,62 ****
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.
--- 47,53 ----
The rationale for scanning subdirectories is that we can move to a
directory-based indexing scheme if the package directory contains
! too many entries. For example, this would let us transparently
! switch from INSTALLDB/Numeric to INSTALLDB/N/Nu/Numeric or some
! similar hashing scheme.
***************
*** 71,99 ****
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
--- 62,90 ----
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.
! 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.
+ FILES 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:
* The file's size
! * The file's permissions, and the owner/group of the file.
! XXX what to do on Windows?
!
! * An MD5 digest of the file, encoded in hex.
* The file's full path, as installed on the system. (XXX
***************
*** 105,125 ****
* 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
--- 96,114 ----
* 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 should
automatically update the database. Packages that roll their own
! installation will have to use the database's API to to manually
! add or update their own entry. System package managers such as
! RPM or pkgadd can just create the new 'package name' file in the
! INSTALLDB directory.
Deliverables
+
+ A description of the database API, to be added to this PEP.
! Patches to the Distutils that 1) implement an InstallationDatabase
class, 2) Update the database when a new package is installed. 3)
a simple package management tool, features to be added to this
***************
*** 127,130 ****
--- 116,135 ----
+ Rejected Suggestions
+
+ Instead of using one text file per package, one large text file or
+ an anydbm file could be used. This has been rejected for a few
+ reasons. First, performance is probably not an extremely pressing
+ concern as the package database is only used when installing or
+ removing packages, a relatively infrequent task. Scalability also
+ likely isn't a problem, as people may have hundreds of Python
+ packages installed, but thousands seems unlikely. Finally,
+ individual text files are compatible with installers such as RPM
+ or DPKG because a package can just drop the new database file into
+ the database directory. If one large text file or a binary file
+ were used, the Python database would then have to be updated by
+ running a postinstall script.
+
+
References
***************
*** 136,140 ****
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
--- 141,145 ----
Ideas for this PEP originally came from postings by Greg Ward,
! Fred L. Drake Jr., Thomas Heller, Mats Wichmann, and others.
Many changes and rewrites to this document were suggested by the