First version of the PEP.

pep-0297.txt

@@ -0,0 +1,97 @@
+PEP: 0297
+Title: Support for System Upgrades
+Version: $Revision$
+Author: mal@lemburg.com (Marc-André Lemburg)
+Status: Draft
+Type: Standards Track
+Python-Version: 2.3
+Created: 19-Jul-2001
+Post-History: 
+
+Abstract
+
+    This PEP proposes strategies to allow the Python standard library
+    to be upgraded in parts without having to reinstall the complete
+    distribution or having to wait for a new patch level release.
+
+Problem
+
+    Python currently does not allow overriding modules or packages in
+    the standard library per default. Even though this is possible by
+    defining a PYTHONPATH environment variable (the paths defined in
+    this variable are prepended to the Python standard library path),
+    there is no standard way of achieving this without changing the
+    configuration.
+
+    Since Python's standard library is starting to host packages which
+    are also available separately, e.g. the distutils, email and PyXML
+    packages, which can also be installed independently of the Python
+    distribution, it is desireable to have an option to upgrade these
+    packages without having to wait for a new patch level release of
+    the Python interpreter to bring along the changes.
+
+Proposed Solutions
+
+    This PEP proposes two different but not necessarily conflicting
+    solutions:
+
+    1. Adding a new standard search path to sys.path:
+       $stdlibpath/system-packages just before the $stdlibpath
+       entry. This complements the already existing entry for site
+       add-ons $stdlibpath/site-packages which is appended to the
+       sys.path at interpreter startup time.
+
+       To make use of this new standard location, distutils will need
+       to grow support for installing certain packages in
+       $stdlibpath/system-packages rather than the standard location
+       for third-party packages $stdlibpath/site-packages.
+
+    2. Tweaking distutils to install directly into $stdlibpath for the
+       system upgrades rather than into $stdlibpath/site-packages.
+
+    The first solution has a few advantages over the second:
+
+    * upgrades can be easily identified (just look in
+      $stdlibpath/system-packages)
+
+    * upgrades can be deinstalled without affecting the rest
+      of the interpreter installation
+
+    * modules can be virtually removed from packages; this is
+      due to the way Python imports packages: once it finds the
+      top-level package directory it stay in this directory for
+      all subsequent package submodule imports
+
+    * the approach has an overall much cleaner design than the
+      hackish install on top of an existing installation approach
+
+    The only advantages of the second approach are that the Python
+    interpreter does not have to changed and that it works with
+    older Python versions.
+
+    Both solutions require changes to distutils. These changes can
+    also be implemented by package authors, but it would be better to
+    define a standard way of switching on the proposed behaviour.
+
+Scope
+
+    Solution 1: Python 2.3 and up
+    Solution 2: all Python versions supported by distutils
+
+Credits
+
+    None
+
+References
+
+    None
+
+Copyright
+
+    This document has been placed in the public domain.
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End: