117 lines
3.6 KiB
Plaintext
117 lines
3.6 KiB
Plaintext
PEP: 297
|
||
Title: Support for System Upgrades
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: mal@lemburg.com (Marc-André Lemburg)
|
||
Status: Rejected
|
||
Type: Standards Track
|
||
Created: 19-Jul-2001
|
||
Python-Version: 2.6
|
||
Post-History:
|
||
|
||
Rejection Notice
|
||
|
||
This PEP is rejected for failure to generate significant interest.
|
||
|
||
|
||
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.
|
||
|
||
On some occasions, it may also be desirable to update modules of
|
||
the standard library without going through the whole Python release
|
||
cycle, e.g. in order to provide hot-fixes for security problems.
|
||
|
||
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.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.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
sentence-end-double-space: t
|
||
fill-column: 70
|
||
coding: utf-8
|
||
End:
|