Rejection Notice

This PEP is rejected for failure to generate significant interest.

Abstract

This PEP proposes strategies to allow the Python standard libraryto be upgraded in parts without having to reinstall the completedistribution or having to wait for a new patch level release.

Problem

Python currently does not allow overriding modules or packages inthe standard library per default. Even though this is possible bydefining aPYTHONPATH environment variable (the paths defined inthis variable are prepended to the Python standard library path),there is no standard way of achieving this without changing theconfiguration.

Since Python’s standard library is starting to host packages whichare also available separately, e.g. the distutils, email and PyXMLpackages, which can also be installed independently of the Pythondistribution, it is desirable to have an option to upgrade thesepackages without having to wait for a new patch level release ofthe Python interpreter to bring along the changes.

On some occasions, it may also be desirable to update modules ofthe standard library without going through the whole Python releasecycle, e.g. in order to provide hot-fixes for security problems.

Proposed Solutions

This PEP proposes two different but not necessarily conflictingsolutions:

1. Adding a new standard search path tosys.path:$stdlibpath/system-packages just before the$stdlibpathentry. This complements the already existing entry for siteadd-ons$stdlibpath/site-packages which is appended to thesys.path at interpreter startup time.

   To make use of this new standard location, distutils will needto grow support for installing certain packages in$stdlibpath/system-packages rather than the standard locationfor third-party packages$stdlibpath/site-packages.

2. Tweaking distutils to install directly into$stdlibpath for thesystem 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 restof the interpreter installation
• modules can be virtually removed from packages; this isdue to the way Python imports packages: once it finds thetop-level package directory it stay in this directory forall subsequent package submodule imports
• the approach has an overall much cleaner design than thehackish install on top of an existing installation approach

The only advantages of the second approach are that the Pythoninterpreter does not have to changed and that it works witholder Python versions.

Both solutions require changes to distutils. These changes canalso be implemented by package authors, but it would be better todefine a standard way of switching on the proposed behaviour.

Scope

Solution 1: Python 2.6 and up

Solution 2: all Python versions supported by distutils

Credits

None

References

None

Copyright

This document has been placed in the public domain.