iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Various updates to PEP 405.

This commit is contained in:
Carl Meyer 2012-05-07 10:28:11 -06:00
parent 3cae3480e8
commit f0e5407915
1 changed files with 24 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
pep-0405.txt
View File

@ -225,35 +225,36 @@ Copies versus symlinks
----------------------
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 @@ course this is not hard to do, but it does seem inelegant. OTOH it's
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