[Python-checkins] peps (merge default -> default): Automated merge with http://hg.python.org/peps
vinay.sajip
python-checkins at python.org
Wed May 16 15:51:06 CEST 2012
http://hg.python.org/peps/rev/51369a92dd8a
changeset: 4394:51369a92dd8a
parent: 4361:afe29321dca3
parent: 4393:1d647da3dd16
user: Carl Meyer <carl at oddbird.net>
date: Mon May 07 10:40:57 2012 -0600
summary:
Automated merge with http://hg.python.org/peps
files:
pep-0405.txt | 107 ++++++++++++++++----------------------
1 files changed, 46 insertions(+), 61 deletions(-)
diff --git a/pep-0405.txt b/pep-0405.txt
--- a/pep-0405.txt
+++ b/pep-0405.txt
@@ -226,35 +226,36 @@
----------------------
The technique in this PEP works equally well in general with a copied
-or symlinked Python binary (and other needed DLLs on Windows). Some
-users prefer a copied binary (for greater isolation from system
-changes) and some prefer a symlinked one (so that e.g. security
-updates automatically propagate to virtual environments).
+or symlinked Python binary (and other needed DLLs on Windows).
+Symlinking is preferable where possible, because in the case of an
+upgrade to the underlying Python installation, a Python executable
+copied in a venv might become out-of-sync with the installed standard
+library and require manual upgrade.
There are some cross-platform difficulties with symlinks:
* Not all Windows versions support symlinks, and even on those that
do, creating them often requires administrator privileges.
-* On OSX framework builds of Python, sys.executable is just a stub
+* On OS X framework builds of Python, sys.executable is just a stub
that executes the real Python binary. Symlinking this stub does not
- work with the implementation in this PEP; it must be copied.
- (Fortunately the stub is also small, so copying it is not an issue).
+ work; it must be copied. (Fortunately the stub is also small, and
+ not changed by bugfix upgrades to Python, so copying it is not an
+ issue).
-Because of these issues, this PEP proposes to copy the Python binary
-by default, to maintain cross-platform consistency in the default
-behavior.
+Thus, this PEP proposes to symlink the binary on all platforms except
+for Windows, and OS X framework builds. A ``--symlink`` option is
+available to force the use of symlinks on Windows versions that
+support them, if the appropriate permissions are available. (This
+option has no effect on OS X framework builds, since symlinking can
+never work there, and has no advantages).
-The ``pyvenv`` script accepts a ``--symlink`` option. If this option
-is provided, the script will attempt to symlink instead of copy. If a
-symlink fails (e.g. because they are not supported by the platform, or
-additional privileges are needed), the script will warn the user and
-fall back to a copy.
-
-On OSX framework builds, where a symlink of the executable would
-succeed but create a non-functional virtual environment, the script
-will fail with an error message that symlinking is not supported on
-OSX framework builds.
+On Windows, if ``--symlink`` is not used, this means that if the
+underlying Python installation is upgraded, the Python binary and DLLs
+in the venv should be updated, or there could be issues of mismatch
+with the upgraded standard library. The pyvenv script accepts a
+``--upgrade`` option for easily performing this upgrade on an existing
+venv.
API
@@ -436,6 +437,18 @@
.. _Google Code Search: http://www.google.com/codesearch#search/&q=sys\.prefix&p=1&type=cs
+Impact on other Python implementations
+--------------------------------------
+
+The majority of this PEP's changes occur in the standard library, which is
+shared by other Python implementations and should not present any
+problem.
+
+Other Python implementations will need to replicate the new
+``sys.prefix``-finding behavior of the interpreter bootstrap, including
+locating and parsing the ``pyvenv.cfg`` file, if it is present.
+
+
Open Questions
==============
@@ -469,59 +482,28 @@
really because there's no supporting concept in ``Python/sysconfig``.
-Testability and Source Build Issues
------------------------------------
+OS X Framework builds
+---------------------
-Currently in the reference implementation, virtual environments must
-be created with an installed Python, rather than a source build, as
-the base installation. In order to be able to fully test the ``venv``
-module in the Python regression test suite, some anomalies in how
-sysconfig data is configured in source builds will need to be removed.
-For example, ``sysconfig.get_paths()`` in a source build gives
-(partial output)::
+There have been some reports that the reference implementation does
+not work on an OS X framework build of Python, but it seems to work
+for us. This needs further investigation.
- {
- 'include': '/home/vinay/tools/pythonv/Include',
- 'libdir': '/usr/lib ; or /usr/lib64 on a multilib system',
- 'platinclude': '/home/vinay/tools/pythonv',
- 'platlib': '/usr/local/lib/python3.3/site-packages',
- 'platstdlib': '/usr/local/lib/python3.3',
- 'purelib': '/usr/local/lib/python3.3/site-packages',
- 'stdlib': '/usr/local/lib/python3.3'
- }
+tkinter
+-------
-Need for ``install_name_tool`` on OSX?
---------------------------------------
-
-`Virtualenv uses`_ ``install_name_tool``, a tool provided in the Xcode
-developer tools, to modify the copied executable on OSX. We need
-input from OSX developers on whether this is actually necessary in
-this PEP's implementation of virtual environments, and if so, if there
-is an alternative to ``install_name_tool`` that would allow ``venv``
-to not require that Xcode is installed.
-
-.. _Virtualenv uses: https://github.com/pypa/virtualenv/issues/168
-
-
-Other Python implementations?
------------------------------
-
-We should get feedback from Jython, IronPython, and PyPy about whether
-there's anything in this PEP that they foresee as a difficulty for
-their implementation.
+Tkinter apps currently do not work within a virtual environment.
Reference Implementation
========================
-The in-progress reference implementation is found in `a clone of the
-CPython Mercurial repository`_. To test it, build and install it (the
-virtual environment tool currently does not run from a source tree).
-From the installed Python, run ``bin/pyvenv /path/to/new/virtualenv``
-to create a virtual environment.
-
-The reference implementation (like this PEP!) is a work in progress.
+The reference implementation is found in `a clone of the CPython
+Mercurial repository`_. To test it, build and install it (the virtual
+environment tool currently does not run from a source tree). From the
+installed Python, run ``bin/pyvenv /path/to/new/virtualenv`` to create
+a virtual environment.
.. _a clone of the CPython Mercurial repository: https://bitbucket.org/vinay.sajip/pythonv
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list