python-checkins at python
May 17, 2012, 4:42 PM
Post #1 of 1
(27 views)
Permalink
|
|
peps (merge default -> default): Merged Carl Meyer's updates to PEP 405.
|
|
http://hg.python.org/peps/rev/f5182f1d9c5c
changeset: 4408:f5182f1d9c5c
parent: 4402:2ed614d32a5e
parent: 4407:8cbef1f07cb9
user: Vinay Sajip <vinay_sajip [at] yahoo>
date: Fri May 18 00:42:11 2012 +0100
summary:
Merged Carl Meyer's updates to PEP 405.
files:
pep-0405.txt | 101 +++++++++++++++++++++-----------------
1 files changed, 56 insertions(+), 45 deletions(-)
diff --git a/pep-0405.txt b/pep-0405.txt
--- a/pep-0405.txt
+++ b/pep-0405.txt
@@ -222,6 +222,22 @@
those files when Python is run from the venv.
+Sysconfig install schemes and user-site
+---------------------------------------
+
+This approach explicitly chooses not to introduce a new sysconfig
+install scheme for venvs. Rather, by modifying ``sys.prefix`` we
+ensure that existing install schemes which base locations on
+``sys.prefix`` will simply work in a venv. Installation to other
+install schemes (for instance, the user-site schemes) whose paths are
+not relative to ``sys.prefix``, will not be affected by a venv at all.
+
+It may be feasible to create an alternative implementation of Python
+virtual environments based on a virtual-specific sysconfig scheme, but
+it would be less robust, as it would require more code to be aware of
+whether it is operating within a virtual environment or not.
+
+
Copies versus symlinks
----------------------
@@ -258,6 +274,45 @@
venv.
+Include files
+-------------
+
+Current virtualenv handles include files in this way:
+
+On POSIX systems where the installed Python's include files are found
+in ``${base_prefix}/include/pythonX.X``, virtualenv creates
+``${venv}/include/`` and symlink ``${base_prefix}/include/pythonX.X``
+to ``${venv}/include/pythonX.X``. On Windows, where Python's include
+files are found in ``{{ sys.prefix }}/Include`` and symlinks are not
+reliably available, virtualenv copies ``{{ sys.prefix }}/Include`` to
+``${venv}/Include``. This ensures that extension modules built and
+installed within the virtualenv will always find the Python header
+files they need in the expected location relative to ``sys.prefix``.
+
+This solution is not ideal when an extension module installs its own
+header files, as the default installation location for those header
+files may be a symlink to a system directory that may not be
+writable. One installer, pip, explicitly works around this by
+installing header files to a nonstandard location
+``${venv}/include/site/pythonX.X/``, as in Python there's currently no
+standard abstraction for a site-specific include directory.
+
+This PEP proposes a slightly different approach, though one with
+essentially the same effect and the same set of advantages and
+disadvantages. Rather than symlinking or copying include files into
+the venv, we simply modify the sysconfig schemes so that header files
+are always looked for relative to ``base_prefix`` rather than
+``prefix``. (We also create an ``include/`` directory within the venv
+
+Better handling of include files in distutils/packaging and, by
+extension, pyvenv, is an area that may deserve its own future PEP. For
+now, we propose that the behavior of virtualenv has thus far proved
+itself to be at least "good enough" in practice.
+
+[.Open question: should pyvenv instead simply copy the behavior of
+virtualenv entirely, to avoid introducing unexpected new issues here?]
+
+
API
---
@@ -449,53 +504,6 @@
locating and parsing the ``pyvenv.cfg`` file, if it is present.
-Open Questions
-==============
-
-What about include files?
--------------------------
-
-For example, ZeroMQ installs ``zmq.h`` and ``zmq_utils.h`` in
-``$VE/include``, whereas SIP (part of PyQt4) installs sip.h by default
-in ``$VE/include/pythonX.Y``. With virtualenv, everything works
-because the PythonX.Y include is symlinked, so everything that's
-needed is in ``$VE/include``. At the moment the reference
-implementation doesn't do anything with include files, besides
-creating the include directory; this might need to change, to
-copy/symlink ``$VE/include/pythonX.Y``.
-
-As in Python there's no abstraction for a site-specific include
-directory, other than for platform-specific stuff, then the user
-expectation would seem to be that all include files anyone could ever
-want should be found in one of just two locations, with sysconfig
-labels "include" & "platinclude".
-
-There's another issue: what if includes are Python-version-specific?
-For example, SIP installs by default into ``$VE/include/pythonX.Y``
-rather than ``$VE/include``, presumably because there's
-version-specific stuff in there - but even if that's not the case with
-SIP, it could be the case with some other package. And the problem
-that gives is that you can't just symlink the ``include/pythonX.Y``
-directory, but actually have to provide a writable directory and
-symlink/copy the contents from the system ``include/pythonX.Y``. Of
-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``.
-
-
-OS X Framework builds
----------------------
-
-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
--------
-
-Tkinter apps currently do not work within a virtual environment.
-
-
Reference Implementation
========================
@@ -505,7 +513,7 @@
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
+.. _a clone of the CPython Mercurial repository: http://hg.python.org/sandbox/vsajip#venv
Copyright
--
Repository URL: http://hg.python.org/peps
|
