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 desirable 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 de-installed 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.