Pipenv: pipenv 如何知道当前项目的 virtualenv ？

virtualenv 的名称是项目的根目录名称，加上项目根目录的完整路径的哈希值。 只要您不移动项目，就可以保证名称是唯一的和可预测的。 （AFAICT 这个名称生成逻辑是一个不应依赖的实现细节。）

要安装特定版本的软件包，请使用与 pip 和 requirements.txt 相同的语法，例如pipenv install django==1.11.0 。

@uranusjr这意味着如果我重命名目录，我的项目的 virtualenv 将丢失。 那很糟。 重命名目录可能是一个常见的用例，用户可能会陷入这种情况并想知道他们的环境是如何停止工作的。

如果可能的话，我建议修复它并进入 Pipfile。 或者创建另一个 .pipenv 文件以在每个项目目录中存储此类元数据。

你有什么建议？

感谢您回答这两个问题！

嘿@sachinjain024 ，我们已经对本地元数据文件进行了一些讨论，但维护者的共识是 pipenv 目前不会支持它。

标识项目的目录路径是早期实现的，因为具有相同名称的项目或同一项目的多个副本会导致意外覆盖环境状态。

在实践中，我们发现，与默默地覆盖他们的工作相比，很少有人因为位置是环境的一部分而遇到问题。 Pipenv 毕竟是一个部署管理工具，所以移动目录应该是一个命令修复。

谢谢@nateprewitt。 快速跳转到简单的实现是有意义的。 假设我在后期重命名一个项目，那么这意味着我的环境不存在。

那么在这种情况下我该怎么办呢？

1. 重置环境，因为我已经有了包含包信息的 Pipfile，因此重置环境会很容易。
2. 也以某种方式重命名 virtualenv 目录
3. ？？？

在这种情况下你有什么建议？ 只是好奇，以防我将来遇到这种情况。

您可以使用pew cp轻松复制现有的 virtualenv，但我认为 1. 将是更“规范”的方式。

@sachinjain024 ，每当您需要移动项目目录时，您只需要运行pipenv install即可返回工作状态。 这将为您创建一个具有新哈希的环境，并重新安装从锁定文件到创建它时使用的先前安装相同的所有内容。

如果您发现自己经常这样做，则可能需要使用pew rm old_project-a3de90进行清理。

我不建议使用pew cp除非您正在修改 pipenv 之外的虚拟环境。 在那种情况下，我认为我们必须考虑“保修失效”的情况，因为我们无法可靠地解释各种变化。

谢谢@nateprewitt @uranusjr。 关闭这张票。

这是迄今为止pipenv产生的最糟糕的想法之一。 原因如下：

我在一家公司工作，在那里 Python 用于许多内部项目的测试自动化。 一名测试人员通常会处理其中的一打。 按照惯例，项目的所有测试代码都位于名为tests 。 这意味着，每个测试人员现在都有一堆虚拟环境，它们都称为~/.local/share/virtualenvs/tests-hKjFddnZ - 真棒！ 忘记切换虚拟环境是人的天性，所以，每隔几天我就会被叫到不同的工作站，因为那个工作站的人认为他们安装了他们需要的包，他们运行pipenv install ，但代码中的导入不起作用。 不仅如此，孤立的虚拟环境会随着时间的推移而累积，而且由于它们都有不起眼的名称，因此无法判断我是在删除未使用的环境还是实际使用过的环境。 这意味着在 CI 中，我们每天都会创建数十个甚至数百个虚拟环境。 任何人都无法跟踪具有基本上随机名称的环境，而且它们太多了，所以我们必须至少每天删除一次。 我们在等待时间上付出了巨大的代价，只是因为pipenv和我们公司的某个人做出了这个超级明智的决定，他们决定使用它......

在 bashrc / shell 配置中设置export PIPENV_VENV_IN_PROJECT=1 。
（或更改您的 shell 脚本以在 $PROJECT/.venv 创建一个 venv，然后
pipenv 会有那个）
在 2018 年 3 月 19 日星期一上午 6:28 wvxvw [email protected]写道：

这是迄今为止 pipenv 产生的最糟糕的想法之一。 原因如下：

我在一家公司工作，在那里 Python 被用于很多测试自动化
内部项目。 一名测试人员通常会处理其中的一打。 经过
约定，项目的所有测试代码都位于名为 tests 的目录中。
这意味着，每个测试人员现在都有一堆虚拟环境
叫做 ~/.local/share/virtualenvs/tests-hKjFddnZ -
惊人的！ 忘记切换虚拟环境是人的天性，所以，
每隔几天我就会被叫到一个不同的工作站，因为那个人
在那个工作站认为他们安装了他们需要的包，他们
运行 pipenv install，但代码中的导入不起作用。 不仅
也就是说，孤立的虚拟环境会随着时间的推移而积累，但由于所有
他们中有不起眼的名字，无法判断我是否正在删除
未使用的环境，或实际使用过的环境。 这
意味着在 CI 中，我们创建了数十个甚至数百个虚拟环境
日常。 任何人都无法跟踪具有
基本上是随机的名字，而且实在是太多了，所以我们必须
每天至少删除一次。 我们在等待时间付出了巨大的代价
仅仅因为 pipenv 和其他人做出的这个超级聪明的决定
我们公司，谁决定使用它...

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

@jtratner那么，如果我要手动创建虚拟环境，为什么还需要pipenv ？

虚拟环境本身就是一项工作。 它到处都是蹩脚的并且在 Windows 上被破坏（它假设在 MS Windows 上，所有地方的默认主目录都称为“~”）。 我希望如果有人要重做 PIP 和虚拟环境，他们会，你知道的，修复他们前辈的明显错误......相反，这种混乱乘以一层不兼容。

你在做错误的假设。 Pipenv 不会重做 virtualenv 或 pip。 它建立在它们之上。

@uranusjr这是一个阅读理解问题。 我非常清楚pipenv作用，因为我花在调试代码上的时间比我想要的要多得多。 重做虚拟环境和 PIP 是该项目的既定目标。 那，而不是修复它们，它决定“按原样”使用它们是pipenv另一个巨大错误，然后是使用click库，并且列表还在继续。

重做虚拟环境和 PIP 是该项目的既定目标。

哪里有人说这个？

我还发现这种行为很奇怪，我希望pipenv为 virtualenv 目录选择一个标准名称并将该目录放在当前目录中，类似于npm使用node_modules 。

@Flimm export PIPENV_VENV_IN_PROJECT=1 。 阅读文档。

@uranusjr我阅读了所有https://docs.pipenv.org和https://docs.pipenv.org/basics/ ，除非我错过了它，否则它从未提到virtualenv目录的安装位置，它也不会警告任何人重命名或移动项目目录将导致必须重新创建virtualenv目录。

PIPENV_VENV_IN_PROJECT命名混乱，因为pipenv不使用标准库中提供的venv ，它使用virtualenv ，这是一个不同的项目。

我只是想就我在熟悉这个项目时绊倒的事情提供反馈。

@Flimm重点是抽象这些信息。 如果您知道管理 virtualenvs 的其他工具如何工作，您应该已经知道移动 virtualenvs 文件夹会使它们无法找到。 如果您不熟悉，您可能一开始就不会去挖掘它。

至于我们使用什么后端库来生成virtualenvs以及环境变量的命名，前者并不那么重要，后者是被广泛接受的速记。 虽然细节很重要，但这一点并不觉得它会给任何人带来任何问题，而且您的主要反对意见似乎是基于您不确定我们使用哪个后端将 Python 可执行文件放入文件夹中。 如果您遇到错误，请报告它们。 我们真的不会改变环境变量_只是因为_。

环境变量在文档中很容易获得： http :

@techalchemy通过其他工具，我猜您的意思是virtualenvwrapper 。 我多年来没有使用virtualenvwrapper 。 我猜测熟悉 Node/NPM 的node_modules模式的 Python 开发人员的数量要大于熟悉virtualenvwrapper或pipenv模式的 Python 开发人员的数量

我在另一个问题 #1919 中对PIPENV_VENV_IN_PROJECT的命名中对venv而不是virtualenv的混淆引用进行venv评论。 我只想说，我不完全持有我认为你认为我持有的位置。

无论如何，原始问题中的问题得到了回答。 我不想延长这个讨论，如果你想要的话，请随意说最后一句话。

我知道这是错误的观众，但由于这个讨论正在进行......好吧，我不认为node_modules是pipenv的灵感来源，而不是virtualenv要么。 我的猜测在历史上可能是不正确的，但是必须同时使用rbenv和virtualenv ，我可以告诉你， virtualenv感觉要么是一个没有理解的糟糕副本，要么也许是早期的原型，由rbenv 。 无论哪种情况，与rbenv相比， virtualenv都是笑柄，原因如下：

它为每个环境复制包。 这是愚蠢的、缓慢的和令人困惑的。 这只是一个糟糕的设计决定，但更可能只是缺乏决定：它只是这样发生，因为有人编写了一些代码将这些包放入任意目录。 最重要的是，它实际上不适用于 Windows。 以至于它从未真正在 Windows 上进行过测试......关于它的一件荒谬的事情是它测试操作系统，一旦发现它在 Windows 上运行，它将主目录设置为~ ，这是默认值稍后可能会被某些环境变量覆盖，但是如果您实际上尝试在受监督且干净的环境中运行自动化... virtualenv将永远不会将软件包安装在同一目录中。

所以... pipenv声称是人类的工具，有点像requests ... 我猜？ 所以，它应该改进它的前辈所做的不成熟的努力......好吧，如果你想制作一个和你之前做同样的事情但更好的程序，这似乎是要走的路，对吧? 然而，它没有扔掉virtualenv的垃圾，而是按原样使用它。 包装器与包装程序的唯一不同之处在于它不允许/使使用包装程序中的某些功能变得更加困难......

在我的生活中，我见过很多尝试进行自动化的尝试，这很糟糕，但是你们正在为明星而努力，甚至在您提供任何有用的信息之前，您就将所有这些不值得的评估放在了您的网站上。 但你没有兑现承诺。 实际上，你只是在操纵舆论，没有做任何实际工作。 而现在不得不做自动化的程序员需要面对另一个邪恶，仅仅因为有人想在 GitHub 上获得更多的“喜欢”……

@wvxvw确实你是不正确的。 virtualenv 比 rbenv 早五（四，见下文）年，因此永远不会受到它的启发。 它们也是根本不同的东西，最终只能达到相似的目标。 您正在寻找的东西（受 rbenv 启发的运行时管理工具）是 pyenv。

还有关于 virtualenv 与其他工具不同的问题——你知道它已经存在十 (10) 年了吗？ 软件开发需求变化很大，它所做的假设已经逐渐过时，没有人愿意加紧取代它。 你足够在意要站出来吗？

我理解每个人都应该有机会发言，但是在对主题没有一点了解的情况下加入讨论，并立即开始指责，这对整个 Pipenv、virtualenv 和 Python 打包系统的贡献者来说是非常粗鲁的。 请不要这样做。

编辑：我做了一些挖掘。 virtualenv 的初始版本 0.8 是在 2007 年发布的，而 rbenv (0.1) 是 2011 年，因此它们相隔四年，而不是五年。

@wvxvw我只看到你提出侮辱。 这种态度在这里真的不受欢迎。 在您继续发帖之前，请查看我们的行为准则。

更改项目路径并丢失原始 virtualenv 映射后，我遇到了同样的问题，然后我阅读了此线程。 首先，我感谢 pipenv 团队的工作。 刚刚得到了一些我想分享的关于这次讨论的意见：

1. 文档确实应该指出项目路径和环境之间的映射机制，至少警告用户changing project path would cause unmapping the original env 。

2. 如果可以在 Pipfile 中手动设置 env 的路径会更好吗？ 我的意思是人们可能对手动使用相同的 env 有一些特殊要求。

只是我的看法与大家分享。

完全不清楚如何使用pipenv。 一个项目是否应该有多个虚拟环境？ 我应该在项目之间共享虚拟环境吗？ 如果仅该项目需要 python 版本，如何使用 pipenv 为特定项目安装不同的 python 版本？ 在这个话题中，每个人都充满了自我，假设了一堆关于其他人的事情，从不试图了解其他人来自哪里。 当我在主页上看到pipenv的好评时，我相信它会对我有所帮助。 相反，我浪费了 5 天的时间来处理它，现在我想我回到 pyenv 因为那至少在某种程度上是确定性的。

如果要在一个项目中使用多个环境，请使用 tox。 使用 pipenv 作为您的主要开发环境，并使用 tox 在多个 python 版本上进行测试。

@ashnur你显然需要做点什么。 与其在由志愿者运营的开源项目中散布消极情绪，不如尝试贡献一些有用的东西？

@uranusjr
这是散列发生的地方？

我正在做一个项目，需要计算路径的哈希值。

@devxpy 是的，没错。

我认为你们应该写一个关于如何使用 pipenv 设置 virtualenv 的基本教程，这是一些非常基本的东西，因为它对人们来说越容易，就会有越多的人使用它，但如果它引起混乱，那么更多的人可能不会使用它，可能会寻求其他在那里构建项目的语言或方法

@uranusjr默认情况下，Pipenv 不在项目目录中创建 virtualenv 的原因是什么？ 在我看来，当项目被重命名/移动/删除时，它将解决孤立环境的问题。 此外，对于那些（有点理所当然地）期望它像 npm 一样工作的人来说，它不会那么令人困惑。

除了传统之外，更喜欢这种方法有什么好处吗？

只需在 pipenv install 命令之前创建 .venv 目录。 实际上，欢迎使用 pipenv 安装的 —venv 或 —dot-venv 选项:)

从 2018.10.9 开始，还有另一种方法可以做到这一点。 您可以添加包含虚拟环境路径的.venv文件。 （偷偷摸摸的新功能！）

@andrewpeterprifer因为我们曾经这样做过，并且需要更改它，因为有些人非常强烈地拒绝了它。 我们需要选择一种或另一种方法，我不得不承认，不将虚拟环境放在项目目录中是更好的默认设置。

ps 你（或任何人）有兴趣写一篇关于这个的常见问题吗？ 这可能需要几段时间，但我很乐意解释是否有人承诺花时间润色文本并提交 PR。

@uranusjr我很好奇为什么它是更好的默认设置。 我是 python 的相对菜鸟，现在我觉得我错过了一些关于最佳实践的明显内容。 ：） 谢谢！

PS.：如果你解释为什么事情是这样的，我可以写一个常见问题条目。 ;)

从 2018.10.9 开始，还有另一种方法可以做到这一点。 您可以添加包含虚拟环境路径的.venv _file_。 （偷偷摸摸的新功能！）

@andrewpeterprifer因为我们曾经这样做过，并且需要更改它，因为有些人非常强烈地拒绝了它。 我们需要选择一种或另一种方法，我不得不承认，不将虚拟环境放在项目目录中是更好的默认设置。

ps 你（或任何人）有兴趣写一篇关于这个的常见问题吗？ 这可能需要几段时间，但我很乐意解释是否有人承诺花时间润色文本并提交 PR。

我很抱歉碰到......我有同样的需要移动具有使用pipenv创建的虚拟环境的项目文件夹。

目前我执行以下操作并且完全没有问题：

• 我将项目文件夹移动到任何我想要的地方
• 在 C:\Users\user\.virtualenvs 我删除了与我刚刚移动的项目关联的 venv 的文件夹
• 我通过 cmd 导航到新的项目文件夹位置并运行 pipenv install （或 pipenv shell 然后 pipenv sync）

一切正常。 这是一种不好的做法吗？

关于@uranusjr评论，如果我对新功能的理解正确，我应该将 .venv 文件（包含所需虚拟环境的路径）添加到项目文件夹中，对吗？ 这将避免我必须执行我之前提到的所有步骤？ 如果是这样就太好了！！
如果是这种情况，那么如果在最初创建虚拟环境时在项目文件夹中自动创建这样的文件不是更好吗？

PS：我也愿意写一个FAQ

其实我觉得@gioxc88的想法不错，一个新创建的virtualenv可以在项目根目录下自动生成.env文件，里面包含PATH这样的env配置。 它将使环境对开发人员更透明，并提供更方便的重新配置方式。

我会尽量一起回答你的问题。 这种方法还不错（IMO；我自己也使用相同的设置）。 然而，不知情的用户更容易被绊倒。

考虑它的一种方法是考虑将项目置于版本控制中（例如 Git）。 如果环境是在项目根目录中创建的，它自然会在存储库根目录中。 像你我这样习惯这种设置的人，显然知道我们应该在.gitignore （或全局忽略配置）中添加一个规则来防止.venv目录被签入，但是一个毫无戒心的用户不会，并且很容易意外地检查环境。 这不仅不利于项目管理，而且（更重要的是）通过暴露本地信息为潜在攻击提供了一个载体。 因此，避免将生成的文件放在项目目录中是项目管理工具的一般规则。 如果您从头开始设计生态系统（例如 NPM 的node_modules ），这样做可能没问题（仍然不是最佳的 IMO），但对于为具有既定惯例的生态系统构建的工具，绝对不是一个好主意，以 Pipenv 为例。

如果默认情况下在项目根目录之外生成环境，则在发布项目（例如将其推送到 GitHub）时，担心的事情就少了一件。 它让我们（更喜欢项目内环境的人）生活变得更加困难，但从风险的角度来看，可能发生的最坏情况是不小心移动了项目并破坏了环境，或者在删除项目时忘记删除环境. 与意外将潜在的敏感环境信息推送到 GitHub 相比，两者都更容易恢复。

.venv文件功能仍然很新（仅在几天前发布），我们仍在探索最佳利用它的方法。 它仍然存在.venv目录的相同问题，但希望没有那么糟糕。 我自己真的很喜欢这个功能，当然希望我们可以用它来改善用户体验，但这里还有很多需要考虑的地方。

你好。 对我来说，.venv 目录（旧功能）和 .venv 文件（新功能）都可以，但我非常感谢在 pipenv install 命令中有一个选项。

就像是：

pipenv install

将安装在~/.local/

pipenv install --venv

将安装在$PWD/.venv目录中

pipenv install --venv-dir /my/custom-path

将安装在/my/custom-path 。

如果您想要一个新功能，请通过向~/.peeps提出增强建议来适当地提出它。 请不要在各种问题周围随机散布增强建议，这是不可追踪的。

@uranusjr谢谢你的详细回答！ 只是为了满足我的好奇心，在 python venv 中检查可以暴露什么样的本地（潜在敏感）信息？ 我同意如果 node_modules 被签入很烦人，但通常不会包含任何本地信息。

Python 虚拟环境包含多个 shell 脚本（例如activate ）。 许多人修改它们以添加环境变量以指定数据库密码、另一个配置文件的路径等。在虚拟环境中修改脚本是违反最佳实践的，但人们仍然这样做（并且当你告诉他们停止这样做时会变得防御-个人经验）。

另外，您是对的， node_modules可能不包含敏感信息。 当您从头开始构建生态系统时，这是另一个好处。 不幸的是，Python 虚拟环境是在这是一个常见问题之前发明的（那时如果你使用 VCS，你就已经是大师了）。

当我试图了解 pipenv 如何知道正确的 virtualenv 时，我到达了这里 :)

谢谢你们的讨论。 或许，在主页（例如，这里）中指定重命名项目路径会破坏 virtualenv 绑定的默认机制可能是一个好主意。

所有文档页面都开放供贡献。 不求东西，去做吧:)

我将会！

@uranusjr这意味着如果我重命名目录，我的项目的 virtualenv 将丢失。 那很糟。 重命名目录可能是一个常见的用例，用户可能会陷入这种情况并想知道他们的环境是如何停止工作的。

如果可能的话，我建议修复它并进入 Pipfile。 或者创建另一个 .pipenv 文件以在每个项目目录中存储此类元数据。

你有什么建议？

感谢您回答这两个问题！

感谢您提出这两个问题。 我也遇到同样的问题

如果您在错误的目录中初始化了 pipenv 并且必须使用正确目录中的 virtualenv 目录，您可以通过执行pipenv --venv并移动PIpfile和Pipfile.lock来获取 virtualenv 路径到正确的目录。

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv在正确的目录中，它应该可以正常工作。

我今天注意到，如果父目录中有一个 pipfile，pipenv 会忽略环境变量export PIPENV_VENV_IN_PROJECT=1并在父目录中安装一个 venv。 这是在发布2018.11.26 。 如果您从父目录中删除 pipfile，pipenv 会按文档中的说明工作。