Various updates to PEP 405.
This commit is contained in:
parent
3cae3480e8
commit
f0e5407915
68
pep-0405.txt
68
pep-0405.txt
|
@ -225,35 +225,36 @@ Copies versus symlinks
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
The technique in this PEP works equally well in general with a copied
|
The technique in this PEP works equally well in general with a copied
|
||||||
or symlinked Python binary (and other needed DLLs on Windows). Some
|
or symlinked Python binary (and other needed DLLs on Windows).
|
||||||
users prefer a copied binary (for greater isolation from system
|
Symlinking is preferable where possible, because in the case of an
|
||||||
changes) and some prefer a symlinked one (so that e.g. security
|
upgrade to the underlying Python installation, a Python executable
|
||||||
updates automatically propagate to virtual environments).
|
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:
|
There are some cross-platform difficulties with symlinks:
|
||||||
|
|
||||||
* Not all Windows versions support symlinks, and even on those that
|
* Not all Windows versions support symlinks, and even on those that
|
||||||
do, creating them often requires administrator privileges.
|
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
|
that executes the real Python binary. Symlinking this stub does not
|
||||||
work with the implementation in this PEP; it must be copied.
|
work; it must be copied. (Fortunately the stub is also small, and
|
||||||
(Fortunately the stub is also small, so copying it is not an issue).
|
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
|
Thus, this PEP proposes to symlink the binary on all platforms except
|
||||||
by default, to maintain cross-platform consistency in the default
|
for Windows, and OS X framework builds. A ``--symlink`` option is
|
||||||
behavior.
|
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
|
On Windows, if ``--symlink`` is not used, this means that if the
|
||||||
is provided, the script will attempt to symlink instead of copy. If a
|
underlying Python installation is upgraded, the Python binary and DLLs
|
||||||
symlink fails (e.g. because they are not supported by the platform, or
|
in the venv should be updated, or there could be issues of mismatch
|
||||||
additional privileges are needed), the script will warn the user and
|
with the upgraded standard library. The pyvenv script accepts a
|
||||||
fall back to a copy.
|
``--upgrade`` option for easily performing this upgrade on an existing
|
||||||
|
venv.
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
API
|
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``.
|
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
|
OS X Framework builds
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
The reference implementation currently does not work on an OS X
|
There have been some reports that the reference implementation does
|
||||||
framework build of Python.
|
not work on an OS X framework build of Python, but it seems to work
|
||||||
|
for us. This needs further investigation.
|
||||||
|
|
||||||
|
|
||||||
tkinter
|
tkinter
|
||||||
|
|
Loading…
Reference in New Issue