[Python-checkins] peps: Various updates to PEP 405.

[vinay.sajip]

http://hg.python.org/peps/rev/1d647da3dd16
changeset:   4393:1d647da3dd16
user:        Carl Meyer <carl at oddbird.net>
date:        Mon May 07 10:28:11 2012 -0600
summary:
  Various updates to PEP 405.

files:
  pep-0405.txt |  67 ++++++++++++++-------------------------
  1 files changed, 24 insertions(+), 43 deletions(-)


diff --git a/pep-0405.txt b/pep-0405.txt
--- a/pep-0405.txt
+++ b/pep-0405.txt
@@ -225,35 +225,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
@@ -480,33 +481,12 @@
 really because there's no supporting concept in ``Python/sysconfig``.
 
 
-Testability and Source Build Issues
------------------------------------
-
-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)::
-
-    {
-     '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'
-    }
-
-
 OS X Framework builds
 ---------------------
 
-The reference implementation currently does not work on an OS X
-framework build of Python.
+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.
 
 
 tkinter

-- 
Repository URL: http://hg.python.org/peps