117 lines
3.3 KiB
ReStructuredText
117 lines
3.3 KiB
ReStructuredText
PEP: 297
|
|
Title: Support for System Upgrades
|
|
Author: Marc-André Lemburg <mal@lemburg.com>
|
|
Status: Rejected
|
|
Type: Standards Track
|
|
Content-Type: text/x-rst
|
|
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.
|