Pipenv: 如果可用，请使用 venv 而不是 virtualenv

我不这么认为，我更喜欢个人使用 virtualenv 命令

也许有可能让两种选择共存？ 随便浏览一下源代码，除了用于创建 env 的命令外，我没有看到任何与 Virtualenv 相关的内容。 Virtualenv 始终可以是默认值，但用户可以（例如）通过--venv .venv使用python3 -m venv而不是virtualenv来创建.venv virtualenv 。

老实说，我完全依赖 pipenv 并且不在乎是否使用了 virtualenv 或 venv，但认为我们可以在可用时利用内置函数。

我敦促@kennethreitz在这里重新考虑他的评论。 标准文档推荐使用python3 -m venv而不是 virtualenv 。 我个人推迟使用 pipenv，因为它使用 virtualenv。 我只使用 Python 3，现在只使用venv 。

@bulletmark现在 Pipenv 将几乎所有 Virtualenv 管理委托给 Pew，切换更加困难，但是 Pew 有计划支持venv但是（berdario/pew#67）所以仍有机会。 如果 Pew 可以让它工作，那么在 Pipenv 中实现venv支持会容易得多（至少对我来说更有意义）。

@uranusjr听起来很棒！

我个人从未使用过venv ，因此我对它感到担忧。 不过我确定它很好。

事情进展顺利，现在。 无需更改未损坏的东西。

我终于找到了这个线程，因为我的系统坏了。

如果您在 Python 3.X 中使用virtualenv创建环境，然后升级到 Python 3.Y，则 virtualenv 会损坏，因为您知道 Python 不再需要共享库。 使用venv您可以运行python3 -m venv --upgrade 。

这将是一个不错的功能。

这肯定会很好，并且感觉符合 Python 的方向

不使用 venv（而是使用 virtualenv）对我来说完全是个障碍——我不能使用 Pipenv。 我不能使用 virtualenv，因为它复制 python 二进制文件的令人沮丧的行为，但又依赖于共享库 - 正如上面发现的 dhouck 对上面的不满。 这会一直破坏 virtualenvs（每当系统 python 更新时，二进制文件悬空），并且不必要地复制 python 二进制文件，绝对没有任何好处。

如果 pipenv 是 Python 的未来，它应该默认在 Python 3 上使用 venv（并在不使用时发出警告）。 它内置于 Python 3 中，是推荐的工具。 很奇怪，现在 Pipenv 也是推荐工具，但它不使用 venv。

venv 本质上是 Python 的一部分，它本身可以访问 Python 的内部结构，这意味着它可以用更少的 hack 以正确的方式做事。 例如，virtualenv 必须将 Python 解释器二进制文件复制到虚拟环境中以诱使它认为它是孤立的，而 venv 可以只使用 Python 二进制文件在其正常位置读取的配置文件，以便它知道它应该采取行动就像在虚拟环境中一样。 因此，在 Python 开发人员的祝福和支持下，venv 可以被认为是 virtualenv 做得对。

来源： https :

我已经开始使用 berdario/pew#173，但没有太多时间取得进展。 如上所述，一旦 Pew 支持，Pipenv 将自动支持。 如果有人有兴趣将 venv 带到 Pipenv，我需要一些帮助。 现在的主要问题是让测试通过。

venv 支持的快速更新：它不会发生，至少在不久的将来。 venv根本不足以实现这一目标。 如果您真的很关心这个，请前往Python 错误跟踪器并伸出援手。 否则，坚持virtualenv 。

venv 是 Python 的推荐工具，它没有损坏，就像 virtualenv 一样（重新：复制 python 二进制文件，然后在 python 库更新时中断）。 您链接到的错误是关于结合 venv 和 virtualenv，这不是我们所要求的？

不幸的是，工具在 virtualenv 上构建是非常普遍的。 例如，Travis 使用 virtualenv 为您创建构建环境，正如原始记者所提到的。 它也是 Pipsi 的基础，它是安装 Pipenv 的推荐方式之一。 如果 venv 在里面不能正常工作。 它在很多地方你都不知道。 如果它不能很好地与 virtualenv 一起工作，Venv 支持将被破坏一半并以意想不到的方式咬你。

我理解这一点，但此时建议使用 Pipenv，建议使用 venv，它们有点冲突。 这是一个非常奇怪的状态。

我完全同意它处于一种奇怪的状态，这就是我试图修复它的原因:) 我不是说它不会被修复，但它需要首先发生上游更改，并且在他们之前我无能为力发生。 我张贴链接不是作为停止工作的借口，而是让人们知道首先应该在哪里努力以帮助改善这种情况。

也许让这个问题保持开放状态不会太疯狂？

这是一个 pew 问题，而不是 pipenv 问题。

venv 根本不足以实现这一目标。 如果您真的很关心这个，请前往Python 错误跟踪器并伸出援手。

不是venv的问题，而是virtualenv的问题。 我在问题跟踪器下发布了一些解释。
抄送@uranusjr

有一个词 - >
首先使用 venv 创建一个 virtualenv，然后运行pipenv install 。 例如：

mkdir -p /tmp/try
cd /tmp/try
python3 -m venv .venv
pipenv --venv  # /tmp/try/.venv
pipenv install xxx

🙈

只是一个注意事项：

上面的解决方法大多有效，但pipenv run ...对我来说失败了，因为activate_this.py下没有.venv/bin 。 如果问题 21496是

使用 virtualenv，在 macOS 中使用 system tk 模块是不可能的。 但是使用venv，这是可能的。
我强烈希望将 venv 与 pipenv 一起使用（可能是可选的）。

另见：#1416

不要听起来愤世嫉俗，但我强烈希望有人真正编写代码来支持这一点，如果他们真的非常关心的话。 我见过很多人说他们对此感到“强烈”，但据我所知，我是唯一一个真正做任何事情的人。 而我失败了。 这并不像你想象的那么简单。 如果你认为你可以做得更好，那就做点什么。 如果你不想，请拿走你能得到的。

（kenneth 和我自己，可能还有 erin 和 nate 在项目的早期也尝试用 venv 来做这件事，但由于兼容性原因也失败了）

这会很好，每个人都同意。 我很想看到它跨平台和 python 版本工作。

我想指出为什么 venv 可能是比 virtualenv 更好的选择的另一个原因：

virtualenv 实现的丑陋方面之一是它必须拥有自己的站点模块副本，该副本用于所有 virtualenv，无论它们是使用哪个版本的 Python 创建的。
-- 来自https://github.com/pypa/virtualenv/issues/228#issuecomment -4165148

这意味着，例如，默认情况下禁用rlcompleter ，在我看来这是一个巨大的可用性损失。

此外，由于这是一个影响多个用户的问题，我建议在问题解决之前保持打开状态，即使您正在等待上游发生一些更改。

再次。 我们知道这样会更好。 这实际上是不可能的。 您认为什么会对大部分用户产生更大的负面影响，完全破坏功能，或者让一些用户必须打开 readline 功能？

我敢肯定这很不方便，而且似乎只有人们要求这样做，但没有人会提供有效的实现，这也很不方便。 我们已经尝试过了。 在发生重大变化之前，我们没有计划支持 venv，因此也没有计划打开这个问题。

@techalchemy如果我理解正确，pypa/virtualenv#1095 是讨论这个的正确地方吗？

看起来是对的，我看到 tox 有一个解决方法，所以如果有人移植它也许会奏效

座位！ 这是什么讨论……如果这个 pew 的事情不是那么重要，是否有可能将它们与 virtualenv 一起丢弃，让 pipenv、venv 和 python 齐头并进，因为它们都相互推荐？

python的依赖管理/虚拟环境解决方案现在太荒谬了，需要做出一些牺牲，恕我直言。

这可能会吓到许多尚未准备好放弃使用 virtualenv 的人，但可以计划在即将发布的主要版本之一（如果技术上可行）。更改是不可避免的，只是时间问题。

@doganmeh我们可以完全放弃 virtualenv，构建一个仅支持 Python 3.3 或更高版本的等效产品，但我想制作另一个项目会更容易。

只是一个注意事项：

上面的解决方法大多有效，但pipenv run ...对我来说失败了，因为activate_this.py下没有.venv/bin 。 如果问题 21496是

那真的有必要吗？ 使用 venv 创建虚拟环境后，您无需激活它即可使用它。 您只需使用来自 venv/bin 目录的 python 二进制文件运行。

FWIW，这是相关的（以及将我带到这里的原因）： http :

在virtualenv 中，即使环境是从框架构建（ virtualenv 错误 #54 ， virtualenv 错误 #609 ）创建的，也会使用非框架构建。

解决方案是不使用 virtualenv，而是使用 stdlib 的venv ，它提供了类似的功能，但没有出现这个问题。

对我来说，放弃 Python 2.7/virtualenv 支持听起来并不是一个特别糟糕的主意，如果它确实允许pipenv依赖于支持即将到期的 Python 版本的 stdlib。 只要它不会破坏维护人员不易修复的pipenv工具链的任何其他部分。 甚至可能将 2.7 支持移至单独的分支/包？

我希望能够贡献实际的代码，但我认为我没有这样做所需的经验或时间 :frown: 目前我能做的最好的事情就是添加到讨论中。

在这里添加我的声音； 我只是因为与@dmtucker相同的问题才遇到这个问题。

我目前在我的 mac 上完全忽略了这个项目的 pipenv，现在用 venv 手工制作环境。

+1 使用 venv。
virtualenv 有许多不会修复的错误。
pipenv 在 Windows 10 上使用 Windows Store 的 Python 3.7 完全有用（virtualenv bug#1362 ）

virtualenv 正在转向 venv 模型 - 请参阅https://github.com/pypa/virtualenv/issues/1366 ，这将生成 pyvenv.cfg 和所有好东西，所以这应该通过它来解决。

- - - - - 转发消息 - - - - -
来自：Dan Ryan通知@github.com
日期：2018 年 11 月 26 日，星期一，下午 2:39
主题：回复：[pypa/pipenv] 如果可用，请使用 venv 而不是 virtualenv (#15)
至：pypa/pipenv [email protected]
抄送：订阅[email protected]

看起来是对的，我看到 tox 有一个解决方法，所以如果
有人把它移植过来

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/pypa/pipenv/issues/15#issuecomment-441533872或静音
线程
https://github.com/notifications/unsubscribe-auth/AqyQvrs-RNNTb1YhxaDCWDLpRxrZLKoxks5uy4ydgaJpZM4Lqk2f
.