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

Incorporated PEP 405 tidy-ups, and marked as Final.

This commit is contained in:
Vinay Sajip 2012-06-05 10:25:18 +01:00
parent b11439d120 ecdcf84254
commit a51d891e28
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
pep-0405.txt
View File

@ -4,7 +4,7 @@ Version: $Revision$
Last-Modified: $Date$
Author: Carl Meyer <carl@oddbird.net>
BDFL-Delegate: Nick Coghlan
Status: Accepted
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 13-Jun-2011
@ -285,15 +285,15 @@ 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``
On POSIX systems where the installed Python's include files are found in
``${base_prefix}/include/pythonX.X``, virtualenv creates
``${venv}/include/`` and symlinks ``${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``.
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
@ -467,10 +467,10 @@ than ``sys.site_prefix`` or the appropriate ``site`` API to find
site-packages directories.
The most notable case is probably `setuptools`_ and its fork
`distribute`_, which mostly use ``distutils``and ``sysconfig`` APIs,
`distribute`_, which mostly use ``distutils`` and ``sysconfig`` APIs,
but do use ``sys.prefix`` directly to build up a list of site
directories for pre-flight checking where ``pth`` files can usefully
be placed.
directories for pre-flight checking where ``pth`` files can usefully be
placed.
Otherwise, a `Google Code Search`_ turns up what appears to be a
roughly even mix of usage between packages using ``sys.prefix`` to