vs安装python模块powershell打不开_win10 下的python虚拟环境安装使用（使用powershell）...

特点

当执行python二进制文件时，它首先要做的确定其前缀(前缀存储在sys.prefix中)；然后使用该前缀查找标准库和其他密钥文件，并由站点模块确定站点包目录的位置。以上是在设置PythonHome环境变量的前提下；假如没设定环境变量，当前的前缀将从遍历文件，通过首先在文件系统树上查找标记文件(os.py)，找到前缀。如果还是找不到，则返回到二进制文件中硬编码的构建时前缀。

PEP的方案是：在此搜索中添加新的第一步。如果pyvenv.cfg文件靠近python.exe文件或其上的一个目录,(如果可执行文件是symlink，则不会取消引用)，则会扫描pyvenv.cfg中的key=value格式行。如果找到了主密钥，这意味着python二进制文件属于虚拟环境，并且主密钥的值是包含用于创建此虚拟环境的python可执行文件的目录。

在这种情况下，前缀查找将继续正常使用主键的值作为有效的Python二进制位置，该位置可查找基本安装的前缀。 sys.base_prefix设置为此值，而sys.prefix设置为包含pyvenv.cfg的目录。

(如果未找到pyvenv.cfg或不包含主键，则前缀查找将继续正常，并且sys.prefix将等于sys.base_prefix。)

此外，添加了sys.base_exec_prefix，并且对sys.exec_prefix进行了类似的处理。 (sys.exec_prefix相当于sys.prefix，但对于特定于平台的文件;默认情况下，它与sys.prefix具有相同的值。)

修改了站点和sysconfig标准库模块，以便找到相对于sys.base_prefix / sys.base_exec_prefix的标准库和头文件，而site-package目录(“purelib”和“platlib”，在sysconfig术语中)仍然是找到相对于sys.prefix / sys.exec_prefix。

因此，最简单形式的Python虚拟环境只包含Python二进制文件的副本或符号链接，并附带pyvenv.cfg文件和site-packages目录。

默认情况下，虚拟环境与系统级site-packages目录完全隔离。

如果pyvenv.cfg文件还包含值为true(不区分大小写)的键include-system-site-packages，则站点模块还将在虚拟环境站点目录之后将系统站点目录添加到sys.path。因此，系统安装的包仍然是可导入的，但是在虚拟环境中安装的同名包将优先。

PEP 370用户级站点包被认为是用于venv目的的系统站点包的一部分：它们不是从隔离的venv中获得的，而是可以从include-system-site-packages = true venv获得。

该PEP还建议在标准库中添加新的venv模块，以实现虚拟环境的创建。可以使用-m标志执行此模块：

python3 -m venv /path/to/new/virtual/environment

还提供了pyvenv安装的脚本，以使这更方便：

pyvenv /path/to/new/virtual/environment

运行此命令将创建目标目录(创建不存在的任何父目录)并在其中放置pyvenv.cfg文件，其中主键指向运行该命令的Python安装。它还创建了一个bin /(或Windows上的Scripts)子目录，其中包含python3可执行文件的副本(或符号链接)，以及来自打包标准库模块的pysetup3脚本(以便于将包从PyPI轻松安装到新的venv中)。它创建了一个(最初为空)lib / pythonX.Y / site-packages(或Windows上的Lib \ site-packages)子目录。

如果目标目录已经存在，则会引发错误，除非提供了--clear选项，在这种情况下，目标目录将被删除，虚拟环境创建将照常进行。

创建的pyvenv.cfg文件还包括include-system-site-packages密钥，如果pyvenv使用--system-site-packages选项运行，则设置为true，默认情况下为false。

可以为pyvenv提供多个路径，在这种情况下，根据给定的选项，在每个提供的路径上将创建相同的venv。

venv模块还在venv的bin或Scripts目录中为POSIX和Windows系统放置“shell激活脚本”。这些脚本只是将虚拟环境的bin(或Scripts)目录添加到用户shell PATH的前面。这对于虚拟环境的使用并不是绝对必要的(作为venv的python二进制文件的显式路径或者脚本也可以使用)，但它很方便。

为了允许pysetup和其他Python包管理器以与安装到普通Python安装相同的方式将软件包安装到虚拟环境中，并避免在sysconfig中使用sys.base_prefix代替sys.prefix进行特殊套管虚拟环境。适当的，内部虚拟环境布局模仿每个平台上Python安装本身的布局。因此，POSIX系统上的典型虚拟环境布局将是：

pyvenv.cfg

bin/python3

bin/python

bin/pysetup3

include/

lib/python3.3/site-packages/

在Windows系统上：

pyvenv.cfg

Scripts/python.exe

Scripts/python3.dll

Scripts/pysetup3.exe

Scripts/pysetup3-script.py

... other DLLs and pyds...

Include/

Lib/site-packages/

安装到虚拟环境中的第三方软件包将其Python模块放置在site-packages目录中，并将其可执行文件放在bin /或Scripts中。

注意

在正常的Windows系统级安装中，Python二进制文件本身不会进入“Scripts /”子目录，就像在默认的venv布局中一样。这在虚拟环境中很有用，因此用户只需将单个目录添加到其shell PATH中，以便有效地“激活”虚拟环境。

注意

在Windows上，还需要将编译的stdlib模块中的DLL和pyd文件复制或符号链接到env，因为如果从非系统范围的Python安装创建venv，Windows将无法找到Python安装的从venv运行Python时这些文件的副本。

Sysconfig安装方案和用户站点

这种方法明确选择不为venvs引入新的sysconfig安装方案。相反，通过修改sys.prefix，我们确保在sys.prefix上基于位置的现有安装方案将仅在venv中工作。安装到其路径与sys.prefix无关的其他安装方案(例如，用户站点方案)根本不会受到venv的影响。

基于特定于虚拟的sysconfig方案创建Python虚拟环境的替代实现可能是可行的，但它不太健壮，因为需要更多代码才能知道它是否在虚拟环境中运行。

拷贝和符号连接

The technique in this PEP works equally well in general with a copied 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 OS X framework builds of Python, sys.executable is just a stub that executes the real Python binary. Symlinking this stub does not 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).

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).

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.

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 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.

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 sought relative to base_prefix rather than prefix. (We also create an include/ directory within the venv, so installers have somewhere to put include files installed within the env).

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.

The high-level method described above makes use of a simple API which provides mechanisms for third-party virtual environment creators to customize environment creation according to their needs.

The venv module contains an EnvBuilder class which accepts the following keyword arguments on instantiation:

system_site_packages - A Boolean value indicating that the system Python site-packages should be available to the environment. Defaults to False.

clear - A Boolean value which, if true, will delete any existing target directory instead of raising an exception. Defaults to False.

symlinks - A Boolean value indicating whether to attempt to symlink the Python binary (and any necessary DLLs or other binaries, e.g. pythonw.exe), rather than copying. Defaults to False.

The instantiated env-builder has a create method, which takes as required argument the path (absolute or relative to the current directory) of the target directory which is to contain the virtual environment. The create method either creates the environment in the specified directory, or raises an appropriate exception.

The venv module also provides a module-level create function as a convenience:

def create(env_dir,

system_site_packages=False, clear=False, use_symlinks=False):

builder = EnvBuilder(

system_site_packages=system_site_packages,

clear=clear,

use_symlinks=use_symlinks)

builder.create(env_dir)

Creators of third-party virtual environment tools are free to use the provided EnvBuilder class as a base class.

The create method of the EnvBuilder class illustrates the hooks available for customization:

def create(self, env_dir):

"""

Create a virtualized Python environment in a directory.

:param env_dir: The target directory to create an environment in.

"""

env_dir = os.path.abspath(env_dir)

context = self.create_directories(env_dir)

self.create_configuration(context)

self.setup_python(context)

self.post_setup(context)

Each of the methods create_directories, create_configuration, setup_python, and post_setup can be overridden. The functions of these methods are:

create_directories - creates the environment directory and all necessary directories, and returns a context object. This is just a holder for attributes (such as paths), for use by the other methods.

create_configuration - creates the pyvenv.cfg configuration file in the environment.

setup_python - creates a copy of the Python executable (and, under Windows, DLLs) in the environment.

post_setup - A (no-op by default) hook method which can be overridden in third party subclasses to pre-install packages or install scripts in the virtual environment.

In addition, EnvBuilder provides a utility method that can be called from post_setup in subclasses to assist in installing custom scripts into the virtual environment. The method install_scripts accepts as arguments the context object (see above) and a path to a directory. The directory should contain subdirectories "common", "posix", "nt", each containing scripts destined for the bin directory in the environment. The contents of "common" and the directory corresponding to os.name are copied after doing some text replacement of placeholders:

__VENV_DIR__ is replaced with absolute path of the environment directory.

__VENV_NAME__ is replaced with the environment name (final path segment of environment directory).

__VENV_BIN_NAME__ is replaced with the name of the bin directory (either bin or Scripts).

__VENV_PYTHON__ is replaced with the absolute path of the environment's executable.

The DistributeEnvBuilder subclass in the reference implementation illustrates how the customization hook can be used in practice to pre-install Distribute into the virtual environment. It's not envisaged that DistributeEnvBuilder will be actually added to Python core, but it makes the reference implementation more immediately useful for testing and exploratory purposes.