在我的CentOS7.2中，我有python3命令，但是为什么我不能使用pyvenv？
[root@www myProject]# pyvenv --version
-bash: pyvenv: there is no command
[root@www myProject]# python3 --version
Python 3.5.2
[root@www myProject]# which python3
/usr/bin/python3
【问题讨论】：
pyvenv3、pyvenv3.5 和pyvenv-3.5？ （显然没有必要区分 pyvenv3 和 pyvenv2，但发行版可能会选择遵循明确的命名模式，以避免与运行 3.5 的 pyvenv 和运行 2.7 的 pip 混淆。）跨度>
pyvenv 在 3.6 中被弃用，支持使用 python3 -m venv。
您可能想知道这与您的 Python 3.5.2 有什么关系，因为 3.5 make install 从源代码运行 Python 3.5（甚至 3.6）安装程序，您将获得 pyvenv 命令（可能还有 pyvenv3、pyvenv3.5 和/或 @ 987654333@)。但你没有那样做；您使用的是发行版的 Python 3.5。
发行版具有将 Python 等大型包分解为核心包和各种“可选”包（如 python3-pip 或 python3-curses）的悠久传统。不仅是 Red Hat；1 Debian 和 Ubuntu 也将 venv 分离到 python3-venv 包中。他们如何决定什么是“核心”和什么是“可选”是一个复杂的过程，有很多遗留问题，所以我不知道具体原因是什么，但我可以推测。
首先，大多数 linux 用户似乎更喜欢使用pipenv 和/或virtualenv。它们有更多的特性，它们不会被 Python 的冰期发布周期所束缚，你可以使用与 Python 3.4、3.6 甚至 2.7 相同的版本。 2011 年，adding venv seemed like TOOWTDI 消除了不兼容的竞争虚拟环境解决方案，但发生的事情是它们已经相互兼容，而venv 则停滞不前。其实Python官方包装权威2推荐virtualenv for installing packages和pipenv for developing applications，还有the PyPA rejected a suggestion to change that in 2017。
此外，正如 3.6 文档所解释的，pyvenv 被弃用的原因基本上是因为它在提供多个 Python 版本的 Linux 发行版上造成了混乱。
最后：venv 依赖于pip。哪个不是内置的。它是如何工作的？好吧，如果你得到一个 python.org 二进制安装程序，它将包括pip。如果你从源代码构建它，Python (3.4+) 使用ensurepip 引导pip 和setuptools。但这主要是为了方便 Mac 和 Windows 用户，以及构建自定义 Python 版本的人；很少有 Linux 发行版依赖 ensurepip。毕竟，您使用企业稳定发行版的原因是您想要所有经过测试的特定版本，您可以通过安装他们的 python3-pip 软件包来完成，而不是通过从 ensurepip 中获取 kludgy pip 然后做pip install --upgrade pip 以获得一些他们尚未测试的未来版本。因此，除非发行版将他们的pip 合并到他们的python 包中，否则包含venv 没有多大意义。
1。 CentOS 7.2 当然只是复制 RHEL 7.2，因为那是 CentOS 的重点，所以问题是为什么 RHEL 7.2 将venv 设为可选包。
2。 PyPA 到底有多正式？这并不完全清楚——它在 PSF 之下，并使用 python.org SIG，但它保持一个单独的存在。但是如果你看一下所涉及的名字，他们基本上都是同一个人，他们既是 Python 核心开发人员，也是主要 linux 发行版的开发人员。因此，那些发行版关注 PyPA 也就不足为奇了——在这两个地方做决定的是同一个人。
【讨论】：