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

Fix-up formatting.

This commit is contained in:
Georg Brandl 2011-10-30 12:40:47 +01:00
parent 89b311fab3
commit c127893abe
1 changed files with 127 additions and 130 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

257
pep-0404.txt
View File

@ -37,22 +37,22 @@ across multiple Python versions, among other uses.
Existing virtual environment tools suffer from lack of support from Existing virtual environment tools suffer from lack of support from
the behavior of Python itself. Tools such as `rvirtualenv`_, which do the behavior of Python itself. Tools such as `rvirtualenv`_, which do
not copy the Python binary into the virtual environment, cannot not copy the Python binary into the virtual environment, cannot
provide reliable isolation from system site directories. Virtualenv, provide reliable isolation from system site directories. Virtualenv,
which does copy the Python binary, is forced to duplicate much of which does copy the Python binary, is forced to duplicate much of
Python's ``site`` module and manually symlink/copy an ever-changing Python's ``site`` module and manually symlink/copy an ever-changing
set of standard-library modules into the virtual environment in order set of standard-library modules into the virtual environment in order
to perform a delicate boot-strapping dance at every to perform a delicate boot-strapping dance at every startup.
startup. (Virtualenv copies the binary because symlinking it does not (Virtualenv copies the binary because symlinking it does not provide
provide isolation, as Python dereferences a symlinked executable isolation, as Python dereferences a symlinked executable before
before searching for `sys.prefix`.) searching for `sys.prefix`.)
The ``PYTHONHOME`` environment variable, Python's only existing The ``PYTHONHOME`` environment variable, Python's only existing
built-in solution for virtual environments, requires built-in solution for virtual environments, requires
copying/symlinking the entire standard library into every copying/symlinking the entire standard library into every environment.
environment. Copying the whole standard library is not a lightweight Copying the whole standard library is not a lightweight solution, and
solution, and cross-platform support for symlinks remains inconsistent cross-platform support for symlinks remains inconsistent (even on
(even on Windows platforms that do support them, creating them often Windows platforms that do support them, creating them often requires
requires administrator privileges). administrator privileges).
A virtual environment mechanism integrated with Python and drawing on A virtual environment mechanism integrated with Python and drawing on
years of experience with existing third-party tools can be lower years of experience with existing third-party tools can be lower
@ -79,7 +79,7 @@ found, falling back to the build-time prefix hardcoded in the binary.
This PEP proposes to add a new first step to this search. If a This PEP proposes to add a new first step to this search. If a
``pyvenv.cfg`` file is found either adjacent to the Python executable, ``pyvenv.cfg`` file is found either adjacent to the Python executable,
or one directory above it, this file is scanned for lines of the form or one directory above it, this file is scanned for lines of the form
``key = value``. If a ``home`` key is found, this signifies that the ``key = value``. If a ``home`` key is found, this signifies that the
Python binary belongs to a virtual environment, and the value of the Python binary belongs to a virtual environment, and the value of the
``home`` key is the directory containing the Python executable used to ``home`` key is the directory containing the Python executable used to
create this virtual environment. create this virtual environment.
@ -105,8 +105,7 @@ regard to ``sys.exec_prefix``.)
Thus, a Python virtual environment in its simplest form would consist Thus, a Python virtual environment in its simplest form would consist
of nothing more than a copy or symlink of the Python binary of nothing more than a copy or symlink of the Python binary
accompanied by a ``pyvenv.cfg`` file and a site-packages accompanied by a ``pyvenv.cfg`` file and a site-packages directory.
directory.
Isolation from system site-packages Isolation from system site-packages
@ -173,9 +172,8 @@ install packages into the virtual environment the same way they would
install into a normal Python installation, and avoid special-casing install into a normal Python installation, and avoid special-casing
virtual environments in ``sysconfig`` beyond using ``sys.site_prefix`` virtual environments in ``sysconfig`` beyond using ``sys.site_prefix``
in place of ``sys.prefix``, the internal virtual environment layout in place of ``sys.prefix``, the internal virtual environment layout
mimics the layout of the Python installation itself on each mimics the layout of the Python installation itself on each platform.
platform. So a typical virtual environment layout on a POSIX system So a typical virtual environment layout on a POSIX system would be::
would be::
pyvenv.cfg pyvenv.cfg
bin/python3 bin/python3
@ -201,7 +199,7 @@ their executables placed in ``bin/`` or ``Scripts\``.
On a normal Windows system-level installation, the Python binary On a normal Windows system-level installation, the Python binary
itself wouldn't go inside the "Scripts/" subdirectory, as it does itself wouldn't go inside the "Scripts/" subdirectory, as it does
in the default venv layout. This is useful in a virtual in the default venv layout. This is useful in a virtual
environment so that a user only has to add a single directory to environment so that a user only has to add a single directory to
their shell PATH in order to effectively "activate" the virtual their shell PATH in order to effectively "activate" the virtual
environment. environment.
@ -219,7 +217,7 @@ 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). Some
users prefer a copied binary (for greater isolation from system users prefer a copied binary (for greater isolation from system
changes) and some prefer a symlinked one (so that e.g. security changes) and some prefer a symlinked one (so that e.g. security
updates automatically propagate to virtual environments). updates automatically propagate to virtual environments).
@ -230,16 +228,15 @@ There are some cross-platform difficulties with symlinks:
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 OSX 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 work with the implementation in this PEP; it must be copied.
copied. (Fortunately the stub is also small, so copying it is not an (Fortunately the stub is also small, so copying it is not an issue).
issue).
Because of these issues, this PEP proposes to copy the Python binary Because of these issues, this PEP proposes to copy the Python binary
by default, to maintain cross-platform consistency in the default by default, to maintain cross-platform consistency in the default
behavior. behavior.
The ``pyvenv`` script accepts a ``--symlink`` option. If this option The ``pyvenv`` script accepts a ``--symlink`` option. If this option
is provided, the script will attempt to symlink instead of copy. If a 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 symlink fails (e.g. because they are not supported by the platform, or
additional privileges are needed), the script will warn the user and additional privileges are needed), the script will warn the user and
@ -259,25 +256,24 @@ provides mechanisms for third-party virtual environment creators to
customize environment creation according to their needs. customize environment creation according to their needs.
The ``venv`` module contains an ``EnvBuilder`` class which accepts the The ``venv`` module contains an ``EnvBuilder`` class which accepts the
following keyword arguments on instantiation:: following keyword arguments on instantiation:
* ``system_site_packages`` - A Boolean value indicating that the * ``system_site_packages`` - A Boolean value indicating that the
system Python site-packages should be available to the system Python site-packages should be available to the environment.
environment (defaults to ``False``). Defaults to ``False``.
* ``clear`` - A Boolean value which, if True, will delete any * ``clear`` - A Boolean value which, if true, will delete any existing
existing target directory instead of raising an exception target directory instead of raising an exception. Defaults to
(defaults to ``False``). ``False``.
* ``use_symlinks`` - A Boolean value indicating whether to attempt * ``use_symlinks`` - A Boolean value indicating whether to attempt to
to symlink the Python binary (and any necessary DLLs or other symlink the Python binary (and any necessary DLLs or other binaries,
binaries, e.g. ``pythonw.exe``), rather than copying. Defaults to e.g. ``pythonw.exe``), rather than copying. Defaults to ``False``.
``False``.
The returned env-builder is an object with a ``create`` method, which The returned env-builder is an object with a ``create`` method, which
takes as required argument the path (absolute or relative to the takes as required argument the path (absolute or relative to the
current directory) of the target directory which is to contain the current directory) of the target directory which is to contain the
virtual environment. The ``create`` method either creates the virtual environment. The ``create`` method either creates the
environment in the specified directory, or raises an appropriate environment in the specified directory, or raises an appropriate
exception. exception.
@ -296,7 +292,7 @@ convenience::
builder.create(env_dir) builder.create(env_dir)
The ``create`` method of the ``EnvBuilder`` class illustrates the The ``create`` method of the ``EnvBuilder`` class illustrates the
hooks available for customization: hooks available for customization::
def create(self, env_dir): def create(self, env_dir):
""" """
@ -312,67 +308,65 @@ hooks available for customization:
self.post_setup(context) self.post_setup(context)
Each of the methods ``create_directories``, ``create_configuration``, Each of the methods ``create_directories``, ``create_configuration``,
``setup_python``, and ``post_setup`` can be ``setup_python``, and ``post_setup`` can be overridden. The functions
overridden. The functions of these methods are:: of these methods are:
* ``create_directories`` - creates the environment directory and * ``create_directories`` - creates the environment directory and all
all necessary directories, and returns a context object. This is necessary directories, and returns a context object. This is just a
just a holder for attributes (such as paths), for use by the holder for attributes (such as paths), for use by the other methods.
other methods.
* ``create_configuration`` - creates the ``pyvenv.cfg`` * ``create_configuration`` - creates the ``pyvenv.cfg`` configuration
configuration file in the environment. file in the environment.
* ``setup_python`` - creates a copy of the Python executable (and, * ``setup_python`` - creates a copy of the Python executable (and,
under Windows, DLLs) in the environment. under Windows, DLLs) in the environment.
* ``post_setup`` - A (no-op by default) hook method which can be * ``post_setup`` - A (no-op by default) hook method which can be
overridden in third party implementations to pre-install packages overridden in third party implementations to pre-install packages or
or install scripts in the virtual environment. install scripts in the virtual environment.
In addition, ``EnvBuilder`` provides a utility method that can be In addition, ``EnvBuilder`` provides a utility method that can be
called from ``post_setup`` in subclasses to assist in installing called from ``post_setup`` in subclasses to assist in installing
scripts into the virtual environment. The method ``install_scripts`` scripts into the virtual environment. The method ``install_scripts``
accepts as arguments the ``context`` object (see above) and a accepts as arguments the ``context`` object (see above) and a
bytestring. The bytestring should be a base64-encoded zip file bytestring. The bytestring should be a base64-encoded zip file
containing directories "common", "posix", "nt", each containing containing directories "common", "posix", "nt", each containing
scripts destined for the bin directory in the environment. The scripts destined for the bin directory in the environment. The
contents of "common" and the directory corresponding to ``os.name`` contents of "common" and the directory corresponding to ``os.name``
are copied after doing some text replacement of placeholders: are copied after doing some text replacement of placeholders:
* ``__VENV_DIR__`` is replaced with absolute path of the * ``__VENV_DIR__`` is replaced with absolute path of the environment
environment directory. directory.
* ``__VENV_NAME__`` is replaced with the environment * ``__VENV_NAME__`` is replaced with the environment name (final path
name (final path segment of environment directory). segment of environment directory).
* ``__VENV_BIN_NAME__`` is replaced with the name of the bin * ``__VENV_BIN_NAME__`` is replaced with the name of the bin directory
directory (either ``bin`` or ``Scripts``). (either ``bin`` or ``Scripts``).
* ``__VENV_PYTHON__`` is replaced with the absolute path of the
environment's executable.
* ``__VENV_PYTHON__`` is replaced with the absolute path of the
environment's executable.
The ``DistributeEnvBuilder`` subclass in the reference implementation The ``DistributeEnvBuilder`` subclass in the reference implementation
illustrates how the customization hook can be used in practice to illustrates how the customization hook can be used in practice to
pre-install Distribute and shell activation scripts into the virtual pre-install Distribute and shell activation scripts into the virtual
environment. It's not envisaged that ``DistributeEnvBuilder`` will be environment. It's not envisaged that ``DistributeEnvBuilder`` will be
actually added to Python core, but it makes the reference actually added to Python core, but it makes the reference
implementation more immediately useful for testing and exploratory implementation more immediately useful for testing and exploratory
purposes. purposes.
The "shell activation scripts" provided by ``DistributeEnvBuilder`` The "shell activation scripts" provided by ``DistributeEnvBuilder``
simply add the virtual environment's ``bin/`` (or ``Scripts\``) simply add the virtual environment's ``bin/`` (or ``Scripts\``)
directory to the front of the user's shell PATH. This is not strictly directory to the front of the user's shell PATH. This is not strictly
necessary for use of a virtual environment (as an explicit path to the necessary for use of a virtual environment (as an explicit path to the
venv's python binary or scripts can just as well be used), but it is venv's python binary or scripts can just as well be used), but it is
convenient. convenient.
This PEP does not propose that the ``venv`` module in core Python will This PEP does not propose that the ``venv`` module in core Python will
add such activation scripts by default, as they are add such activation scripts by default, as they are shell-specific.
shell-specific. Adding activation scripts for the wide variety of Adding activation scripts for the wide variety of possible shells is
possible shells is an added maintenance burden, and is left to an added maintenance burden, and is left to third-party extension
third-party extension tools. tools.
No doubt the process of PEP review will show up any customization No doubt the process of PEP review will show up any customization
requirements which have not yet been considered. requirements which have not yet been considered.
@ -396,11 +390,12 @@ be installed?"
This split could be handled by introducing a new ``sys`` attribute for This split could be handled by introducing a new ``sys`` attribute for
either the former prefix or the latter prefix. Either option either the former prefix or the latter prefix. Either option
potentially introduces some backwards-incompatibility with software potentially introduces some backwards-incompatibility with software
written to assume the other meaning for ``sys.prefix``. (Such software written to assume the other meaning for ``sys.prefix``. (Such
should preferably be using the APIs in the ``site`` and ``sysconfig`` software should preferably be using the APIs in the ``site`` and
modules to answer these questions rather than using ``sys.prefix`` ``sysconfig`` modules to answer these questions rather than using
directly, in which case there is no backwards-compatibility issue, but ``sys.prefix`` directly, in which case there is no
in practice ``sys.prefix`` is sometimes used.) backwards-compatibility issue, but in practice ``sys.prefix`` is
sometimes used.)
The `documentation`__ for ``sys.prefix`` describes it as "A string The `documentation`__ for ``sys.prefix`` describes it as "A string
giving the site-specific directory prefix where the platform giving the site-specific directory prefix where the platform
@ -413,11 +408,11 @@ __ http://docs.python.org/dev/library/sys.html#sys.prefix
This PEP currently proposes to leave ``sys.prefix`` pointing to the This PEP currently proposes to leave ``sys.prefix`` pointing to the
base system installation (which is where the standard library and base system installation (which is where the standard library and
header files are found), and introduce a new value in ``sys`` header files are found), and introduce a new value in ``sys``
(``sys.site_prefix``) to point to the prefix for (``sys.site_prefix``) to point to the prefix for ``site-packages``.
``site-packages``. This maintains the documented semantics of This maintains the documented semantics of ``sys.prefix``, but risks
``sys.prefix``, but risks breaking isolation if third-party code uses breaking isolation if third-party code uses ``sys.prefix`` rather than
``sys.prefix`` rather than ``sys.site_prefix`` or the appropriate ``sys.site_prefix`` or the appropriate ``site`` API to find
``site`` API to find site-packages directories. site-packages directories.
The most notable case is probably `setuptools`_ and its fork The most notable case is probably `setuptools`_ and its fork
`distribute`_, which mostly use ``distutils``/``sysconfig`` APIs, but `distribute`_, which mostly use ``distutils``/``sysconfig`` APIs, but
@ -426,7 +421,7 @@ for pre-flight checking where ``pth`` files can usefully be placed.
It would be trivial to modify these tools (currently only It would be trivial to modify these tools (currently only
`distribute`_ is Python 3 compatible) to check ``sys.site_prefix`` and `distribute`_ is Python 3 compatible) to check ``sys.site_prefix`` and
fall back to ``sys.prefix`` if it doesn't exist (for earlier versions fall back to ``sys.prefix`` if it doesn't exist (for earlier versions
of Python). If Distribute is modified in this way and released before of Python). If Distribute is modified in this way and released before
Python 3.3 is released with the ``venv`` module, there would be no Python 3.3 is released with the ``venv`` module, there would be no
likely reason for an older version of Distribute to ever be installed likely reason for an older version of Distribute to ever be installed
in a virtual environment. in a virtual environment.
@ -434,9 +429,9 @@ in a virtual environment.
In terms of other third-party usage, a `Google Code Search`_ turns up In terms of other third-party usage, a `Google Code Search`_ turns up
what appears to be a roughly even mix of usage between packages using what appears to be a roughly even mix of usage between packages using
``sys.prefix`` to build up a site-packages path and packages using it ``sys.prefix`` to build up a site-packages path and packages using it
to e.g. eliminate the standard-library from code-execution to e.g. eliminate the standard-library from code-execution tracing.
tracing. Either choice that's made here will require one or the other Either choice that's made here will require one or the other of these
of these uses to be updated. uses to be updated.
.. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
.. _distribute: http://packages.python.org/distribute/ .. _distribute: http://packages.python.org/distribute/
@ -454,7 +449,7 @@ considerations in mind:
* Inasmuch as "site" has a meaning in Python, it means a combination * Inasmuch as "site" has a meaning in Python, it means a combination
of Python version, standard library, and specific set of of Python version, standard library, and specific set of
site-packages. This is, fundamentally, what a venv is (although it site-packages. This is, fundamentally, what a venv is (although it
shares the standard library with its "base" site). shares the standard library with its "base" site).
* It is the Python ``site`` module which implements adding * It is the Python ``site`` module which implements adding
@ -466,17 +461,17 @@ overloaded and of unclear meaning, and this usage will increase the
overload. overload.
One proposed alternative is ``sys.venv_prefix``, which has the One proposed alternative is ``sys.venv_prefix``, which has the
advantage of being clearly related to the venv implementation. The advantage of being clearly related to the venv implementation. The
downside of this proposal is that it implies the attribute is only downside of this proposal is that it implies the attribute is only
useful/relevant when in a venv and should be absent or ``None`` when useful/relevant when in a venv and should be absent or ``None`` when
not in a venv. This imposes an unnecessary extra burden on code using not in a venv. This imposes an unnecessary extra burden on code using
the attribute: ``sys.venv_prefix if sys.venv_prefix else the attribute: ``sys.venv_prefix if sys.venv_prefix else sys.prefix``.
sys.prefix``. The prefix attributes are more usable and general if The prefix attributes are more usable and general if they are always
they are always present and set, and split by meaning (stdlib vs present and set, and split by meaning (stdlib vs site-packages,
site-packages, roughly), rather than specifically tied to venv. Also, roughly), rather than specifically tied to venv. Also, third-party
third-party code should be encouraged to not know or care whether it code should be encouraged to not know or care whether it is running in
is running in a virtual environment or not; this option seems to work a virtual environment or not; this option seems to work against that
against that goal. goal.
Another option would be ``sys.local_prefix``, which has both the Another option would be ``sys.local_prefix``, which has both the
advantage and disadvantage, depending on perspective, that it advantage and disadvantage, depending on perspective, that it
@ -489,11 +484,11 @@ Why not modify sys.prefix?
As discussed above under `Backwards Compatibility`_, this PEP proposes As discussed above under `Backwards Compatibility`_, this PEP proposes
to add ``sys.site_prefix`` as "the prefix relative to which to add ``sys.site_prefix`` as "the prefix relative to which
site-package directories are found". This maintains compatibility with site-package directories are found". This maintains compatibility
the documented meaning of ``sys.prefix`` (as the location relative to with the documented meaning of ``sys.prefix`` (as the location
which the standard library can be found), but means that code assuming relative to which the standard library can be found), but means that
that site-packages directories are found relative to ``sys.prefix`` code assuming that site-packages directories are found relative to
will not respect the virtual environment correctly. ``sys.prefix`` will not respect the virtual environment correctly.
Since it is unable to modify ``distutils``/``sysconfig``, Since it is unable to modify ``distutils``/``sysconfig``,
`virtualenv`_ is forced to instead re-point ``sys.prefix`` at the `virtualenv`_ is forced to instead re-point ``sys.prefix`` at the
@ -506,7 +501,7 @@ does this and it doesn't appear to have caused major problems with
existing code. existing code.
Another argument in favor of this is that it would be preferable to Another argument in favor of this is that it would be preferable to
err on the side of greater, rather than lesser, isolation. Changing err on the side of greater, rather than lesser, isolation. Changing
``sys.prefix`` to point to the virtual environment and introducing a ``sys.prefix`` to point to the virtual environment and introducing a
new ``sys.base_prefix`` attribute would err on the side of greater new ``sys.base_prefix`` attribute would err on the side of greater
isolation in the face of existing code's use of ``sys.prefix``. isolation in the face of existing code's use of ``sys.prefix``.
@ -515,13 +510,14 @@ isolation in the face of existing code's use of ``sys.prefix``.
What about include files? What about include files?
------------------------- -------------------------
For example, ZeroMQ installs zmq.h and zmq_utils.h in $VE/include, For example, ZeroMQ installs ``zmq.h`` and ``zmq_utils.h`` in
whereas SIP (part of PyQt4) installs sip.h by default in ``$VE/include``, whereas SIP (part of PyQt4) installs sip.h by default
$VE/include/pythonX.Y. With virtualenv, everything works because the in ``$VE/include/pythonX.Y``. With virtualenv, everything works
PythonX.Y include is symlinked, so everything that's needed is in because the PythonX.Y include is symlinked, so everything that's
$VE/include. At the moment the reference implementation doesn't do needed is in ``$VE/include``. At the moment the reference
anything with include files, besides creating the include directory; implementation doesn't do anything with include files, besides
this might need to change, to copy/symlink $VE/include/pythonX.Y. 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 As in Python there's no abstraction for a site-specific include
directory, other than for platform-specific stuff, then the user directory, other than for platform-specific stuff, then the user
@ -530,26 +526,27 @@ want should be found in one of just two locations, with sysconfig
labels "include" & "platinclude". labels "include" & "platinclude".
There's another issue: what if includes are Python-version-specific? There's another issue: what if includes are Python-version-specific?
For example, SIP installs by default into $VE/include/pythonX.Y rather For example, SIP installs by default into ``$VE/include/pythonX.Y``
than $VE/include, presumably because there's version-specific stuff in rather than ``$VE/include``, presumably because there's
there - but even if that's not the case with SIP, it could be the case version-specific stuff in there - but even if that's not the case with
with some other package. And the problem that gives is that you can't SIP, it could be the case with some other package. And the problem
just symlink the include/pythonX.Y directory, but actually have to that gives is that you can't just symlink the ``include/pythonX.Y``
provide a writable directory and symlink/copy the contents from the directory, but actually have to provide a writable directory and
system include/pythonX.Y. Of course this is not hard to do, but it symlink/copy the contents from the system ``include/pythonX.Y``. Of
does seem inelegant. OTOH it's really because there's no supporting course this is not hard to do, but it does seem inelegant. OTOH it's
concept in Python/sysconfig. really because there's no supporting concept in ``Python/sysconfig``.
Interface with packaging tools Interface with packaging tools
------------------------------ ------------------------------
Some work will be needed in packaging tools (Python 3.3 packaging, Some work will be needed in packaging tools (Python 3.3 packaging,
Distribute) to support implementation of this PEP. For example: Distribute) to support implementation of this PEP. For example:
* How Distribute and packaging use sys.prefix and/or sys.site_prefix. Clearly, * How Distribute and packaging use ``sys.prefix`` and/or
in practice we'll need to use Distribute for a while, until packages have ``sys.site_prefix``. Clearly, in practice we'll need to use
migrated over to usage of setup.cfg. Distribute for a while, until packages have migrated over to usage
of setup.cfg.
* How packaging and Distribute set up shebang lines in scripts which they * How packaging and Distribute set up shebang lines in scripts which they
install in virtual environments. install in virtual environments.
@ -560,10 +557,10 @@ Testability and Source Build Issues
Currently in the reference implementation, virtual environments must Currently in the reference implementation, virtual environments must
be created with an installed Python, rather than a source build, as 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`` the base installation. In order to be able to fully test the ``venv``
module in the Python regression test suite, some anomalies in how module in the Python regression test suite, some anomalies in how
sysconfig data is configured in source builds will need to be sysconfig data is configured in source builds will need to be removed.
removed. For example, sysconfig.get_paths() in a source build gives For example, ``sysconfig.get_paths()`` in a source build gives
(partial output):: (partial output)::
{ {
@ -581,11 +578,11 @@ Need for ``install_name_tool`` on OSX?
-------------------------------------- --------------------------------------
`Virtualenv uses`_ ``install_name_tool``, a tool provided in the Xcode `Virtualenv uses`_ ``install_name_tool``, a tool provided in the Xcode
developer tools, to modify the copied executable on OSX. We need input developer tools, to modify the copied executable on OSX. We need
from OSX developers on whether this is actually necessary in this input from OSX developers on whether this is actually necessary in
PEP's implementation of virtual environments, and if so, if there is this PEP's implementation of virtual environments, and if so, if there
an alternative to ``install_name_tool`` that would allow ``venv`` to is an alternative to ``install_name_tool`` that would allow ``venv``
not require that Xcode is installed. to not require that Xcode is installed.
.. _Virtualenv uses: https://github.com/pypa/virtualenv/issues/168 .. _Virtualenv uses: https://github.com/pypa/virtualenv/issues/168
@ -595,9 +592,9 @@ Activation and Utility Scripts
Virtualenv provides shell "activation" scripts as a user convenience, Virtualenv provides shell "activation" scripts as a user convenience,
to put the virtual environment's Python binary first on the shell to put the virtual environment's Python binary first on the shell
PATH. This is a maintenance burden, as separate activation scripts PATH. This is a maintenance burden, as separate activation scripts
need to be provided and maintained for every supported shell. For this need to be provided and maintained for every supported shell. For
reason, this PEP proposes to leave such scripts to be provided by this reason, this PEP proposes to leave such scripts to be provided by
third-party extensions; virtual environments created by the core third-party extensions; virtual environments created by the core
functionality would be used by directly invoking the environment's functionality would be used by directly invoking the environment's
Python binary or scripts. Python binary or scripts.
@ -634,9 +631,9 @@ Reference Implementation
The in-progress reference implementation is found in `a clone of the The in-progress reference implementation is found in `a clone of the
CPython Mercurial repository`_. To test it, build and install it (the CPython Mercurial repository`_. To test it, build and install it (the
virtual environment tool currently does not run from a source virtual environment tool currently does not run from a source tree).
tree). From the installed Python, run ``bin/pyvenv From the installed Python, run ``bin/pyvenv /path/to/new/virtualenv``
/path/to/new/virtualenv`` to create a virtual environment. to create a virtual environment.
The reference implementation (like this PEP!) is a work in progress. The reference implementation (like this PEP!) is a work in progress.