Automated merge with http://hg.python.org/peps
This commit is contained in:
Carl Meyer
commit
166b723977
110
pep-0405.txt
110
pep-0405.txt
|
|
@ -226,35 +226,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
|
||||
|
|
@ -436,6 +437,18 @@ files. Rationale for this choice:
|
|||
.. _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 @@ 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
|
||||
-----------------------------------
|
||||
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)::
|
||||
|
||||
{
|
||||
'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'
|
||||
}
|
||||
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.
|
||||
|
||||
|
||||
Need for ``install_name_tool`` on OSX?
|
||||
--------------------------------------
|
||||
tkinter
|
||||
-------
|
||||
|
||||
`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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue