[Python-Dev] PEP: Support for System Upgrades

[M.-A. Lemburg]

PEP: 0???
Title: Support for System Upgrades
Version: $Revision: 0.0 $
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:

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/