Pipenv: [问题] 如何与setup.py集成？

您应该能够使用下面的代码完成此操作。 这将从您当前的项目加载 Pipfile 并在 pip 兼容列表中返回依赖项。

from pipenv.project import Project
from pipenv.utils import convert_deps_to_pip

pfile = Project(chdir=False).parsed_pipfile
requirements = convert_deps_to_pip(pfile['packages'], r=False)
test_requirements = convert_deps_to_pip(pfile['dev-packages'], r=False)

如果您有任何其他问题，请告诉我们：）

以上非常有帮助。 我遇到了setup.py的问题，这取决于在setup.py install （或其他任何东西）可以运行之前将 Pipenv 安装在 virtualenv 中。 我能想到的唯一解决方案是将 Pipenv 供应到一个项目中，这似乎不太理想，或者甚至在尝试运行from pipenv...导入之前以某种方式破解 setup.py 来安装 Pipenv，这似乎错误的。 任何人有任何想法或比这更好的解决方案？

我们是否应该向 Python 社区（PyPA 等）中的其他人（PyPA 等）提出建议，让 Pipenv 成为未来 Python 版本中官方包含的工具？ 😄

将pipenv添加到setup_requires会有所帮助吗？ 看起来可能还需要将其添加到install_requires中，这似乎很不幸。

不要这样做。

@kennethreitz “这个”是什么意思？ 您是指与 setup.py、 @nateprewitt解决方案或最后两个建议的集成吗？

那么用户应该如何知道他们需要安装 pipenv 呢？

由于 pipenv 是一个用来安装东西的工具，反之亦然，所以没有理由在 setup.py 中需要它。 Kenneth 警告的事情是在 setup.py 中导入 pipenv，因为它是一个 cli 应用程序并且可能会导致问题。

2017 年 10 月 17 日上午 9 点 37 分，Iddan Ahahronson [email protected]写道：

那么用户应该如何知道他们需要安装 pipenv 呢？

—
您收到此消息是因为您订阅了此线程。
直接回复此电子邮件，在 GitHub 上查看它，或将线程静音。

那么如何在 setup.py 中使用@nateprewitt - 的代码？

@iddan ：我试图通过将 Pipenv 的一个版本供应到我的项目框架中来解决 Pipenv 引导问题（https://github.com/elgertam/cookiecutter-pypackage/blob/master/%7B%7Bcookiecutter.project_slug%7D %7D/setup.py)。 到目前为止，我还没有遇到任何问题，尽管我不能说在使用setup.py安装软件包的情况下我有很多机会对其进行测试。

我可以理解为什么我们会担心在加载 setup.py 时不运行 CLI，但据我所知，我正在使用的代码（从@nateprewitt的帖子复制粘贴在这里）是相当安全的。

我认为当pip有足够的内部结构来理解 Pipfile 格式时，将不再需要这种 hack。

@iddan ，需要明确的是，该代码仅用于将 Pipfiles 依赖项转换为 pip 将读取的 requirements.txt 样式格式。 看起来 Kenneth 从原始帖子中编辑了一些内容，但我不确定是什么。

Pipenv 旨在作为环境管理和部署工具，而不是像 setup.py 这样的分发工具。 我们强烈建议记录您正在使用 Pipfile 并可能链接到 pipenv.org 以获取安装说明。 以与处理 pip 相同的方式处理它，用户不需要在每次安装新的 Python 包时都安装 pip。

我完全理解这一点。 我不明白的是，当用户使用此脚本下载软件包并且没有安装 pipenv 时，您期望会发生什么

@nateprewitt ，如果我们想要分发一个包（通过通常的方式，使用pip ），我们应该在setup.py或requirements.txt中维护依赖列表的副本? 我希望将我的 Pipfile 用作单一的事实来源。

为了澄清，我假设第一个回复中的代码是作为构建的一部分运行的，而不是实际在setup.py中使用。

除非我弄错了，否则https://github.com/kennethreitz/pipenv/issues/209#issuecomment -278185133 中的代码如果您正在构建一个轮子（=binary dist）可以安全使用，但如果您正在构建 sdist (=source dist)。

对于轮子， setup.py不包含在包中（而是在构建时进行评估，元数据文件是根据它收集的信息构建的）。 使用轮子， setup.py永远不会在安装包的机器上执行，只会在构建它的地方执行。

使用 sdist， setup.py实际上是在安装机器上运行的，所以pipenv需要在那里可用。

哦是的。 @tuukkamustonen ，我的特殊用例是 sdist。 由于我不想要求软件包用户在执行pip install pipenv $ ，因此我认为我坚持在setup.py之外派生install_requires $ setup.py （即手动或作为构建的一部分）？

如果我没看错的话，我相信 Kenneth 和其他维护者不希望我们像对待 $#$ pytest $#$ 那样将Pipenv视为项目依赖，甚至是普通的包依赖。 理想情况下，听起来我们应该以与pip本身相同的方式安装和更新Pipenv ，即在安装 Python 或virtualenv pip virtualenv被创建。 这就是肯尼斯说“不要这样做”时的意思。

也就是说， @isobit回应了我的想法，即Pipfile应该是唯一的事实来源。 我可以看到两个支持 Pipfile 的引人注目的用例（还有其他用例）：首先，依赖 Pipfile 来设置构建环境的 CI/CD 管道比依赖于 requirements.txt 的管道要健壮得多； 其次，贡献者可能会盲目地尝试安装基于 Pipfile 的项目，如果python setup.py install没有按照她预期的方式工作，可能会感到沮丧。 考虑到 Pipenv 和 Pipfile-aware pip 都不是标准的 Python 工具，而且 Pipenv 确实是 Pipfile 的参考实现，我们几乎没有办法解决这个问题：

1) 在您的项目文档中指定您的项目依赖于Pipenv 。 您仍然可以在 setup.py 中依赖Pipenv $ ，如果您的 Python 环境中未安装Pipenv setup.py ，这将中断。 具体来说，您的代码的贡献者必须手动将Pipenv安装到她的virtualenv才能使用setup.py安装项目。
2）仍然有 setup.py 依赖于requirements.txt ，您会根据您的Pipfile定期生成它。 这仍然与pip和setuptools完全兼容，但需要任何维护者在构建和部署项目时生成requirements.txt 。 一个可能的变体是 CI/CD 管道在构建时更新requirements.txt 。
3) 将 Pipenv 的版本供应到项目中，并在setup.py中使用from _vendor.pipenv.project import Project...调用它。 一种变体可能是仅在全局导入失败时从供应商版本导入。
4）这里没有提出的其他一些选项，我不够聪明，无法想到。

我个人使用（3）（请参阅 https://github.com/kennethreitz/pipenv/issues/209#issuecomment-300550425），直到 Pipfile 成为更通用的标准，此时我将没有任何项目直接依赖于 Pipenv 代码，因为 Pipenv 似乎显然是一种用于管理基于 Pipfile 的 virtualenv 的工具，而不一定是 Pipfile 库本身。

我希望这可以根据我在这里阅读的内容澄清问题，但如果我说错话或说了一些令人震惊的话，请告诉我@nateprewitt。

我觉得这里的问题源于最初的requirements.txt误用 (IMO)。 这与pipenv的用法有关。

我将指向 Donald Stufft 的这篇精彩文章 setup.py vs requirements.txt：
https://caremad.io/posts/2013/07/setup-vs-requirement/

TL;DR（但您确实应该阅读）： setup.py的install_requires旨在详细说明包的要求（依赖项）。 requirements.txt Pipfile Pipfile.lock来自setup.py的元数据，以创建可重现的环境。
从requirements.txt install_requires $#$ 就像倒退一样。

setup.py的install_requires =/= requirements.txt （或Pipfile / Pipfile.lock ）。
Pipfile （或者更确切地说Pipfile.lock ）应该是要安装在应用程序环境中的软件包的唯一真实来源。
setup.py的install_requires提供用于生成有效Pipfile.lock的元数据。

我认为这就是摩擦的来源。 我希望这是有道理的。

我非常喜欢这个回复，文森特，我完全同意Pipfile.lock是requirements.txt的完整（更好）替代品。

不过，在使用 Pipenv 几个月后，我对Pipfile的使用让我认为install_requires确实与Pipfile中的内容几乎相同。 如果我需要numpy ，我pipenv install numpy和一个新条目进入我的 Pipfile 的[packages]组： numpy = "*" 。 换句话说，我的用法与requirements.txt完全不同，我以前只是在使用pip freeze > requirements.txt提交之前生成它。

也许这只是我使用 Pipenv 的一种特殊方式，而且我正在违背常规（我还将我的 virtualenv 安装在项目目录内的.venv/中，所以我是一个流氓 Pythonista），其中案例我可以很容易地遵守 Python 社区的约定，即在setup.py和Pipfile之间设置一堵墙 | Pipfile.lock | requirements.txt 。

我在这里错过了什么，@vphilippon？

感谢您提供信息，@vphilippon。 也许我们是在倒退，听起来我们真正想要的是相反的——一种在我们的 Pipfile 中使用来自install_requires的抽象 deps 的方法，就像 Donald 在-e . requirements.txt提到的那样

Pipfile 语法是否已经涵盖了这一点？ 我刚刚注意到请求库 Pipfile在其包部分中使用"e1839a8" = {path = ".", editable = true, extras=["socks"]} 。 在Pipfile 示例中类似的东西很明显，但我没有看到任何其他文档。

首先，免责声明：我的专长主要是 lib 包。 我可能会错过一些要点。 我有犯错的权利，我已经准备好使用它了！
此外，这让我有几次挠头。 我真的很想对此进行一些评论。

现在，让我们开始吧。

我将从@elgertam声明开始：

[...] 我对 Pipfile 的使用使我认为 install_requires 确实与 Pipfile 中的内容几乎相同。 如果我需要 numpy，我 pipenv install numpy 并在我的 Pipfile 的 [packages] 组中进入一个新条目 [...]

您将numpy添加到环境中，但没有将numpy添加到应用程序的依赖项中。
这是两个不同的东西。 继续阅读，你会明白我的意思。

换句话说，我的用法与 requirements.txt 完全不同，我以前只是在使用 pip freeze > requirements.txt 提交之前生成的。

令人惊讶的是，如果您考虑一下，您的用法并没有太大的不同：

• 你之前的工作流程： pip install stuff -> pip freeze > requirements.txt -> feed install_requires from requirements.txt
• 您的新（尝试）工作流程： pipenv install stuff -> Pipfile自动更新 -> 尝试使用 $#$9$ install_requires提供Pipfile 。
• 预期的想法是什么：将东西添加到install_requires -> pipenv install -> 环境和Pipfile.lock已更新。

对于这种预期的工作方式，您需要一个Pipfile来说明您要安装您的应用程序。
类似于@isobit 链接的requests Pipfile 。

或者，一个例子：

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"

您的Pipfile是描述您的环境，而不是包的依赖项。 如您所见，上面的Pipfile定义了我要安装的内容，即可编辑模式下的本地包。

这可能看起来有点“无用”，因为现在它全部由一个包驱动，但是假设你想安装你的应用程序，但是使用requests[security] ，但这不是你的应用程序的严格依赖，你做pipenv install requests[security] ，然后：

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"
requests = { extras = ['security'] }

瞧，这是您的抽象要求和具体要求之间差异的示例。 如果您想在环境中安装gunicorn或其他任何需要的东西，也是如此，但这不是应用程序本身的一部分。

我在这里错过了什么，@vphilippon？ 为什么 Pipfile 的 [packages] 太受限制而无法在 install_requires 或 tests_require 中使用？

如果我已经解释得足够好，您可以看到它应该是相反的。
你把你的依赖项放在install_requires中，你把你的包放在Pipfile中，然后你得到环境，带有Pipfile.lock的可重复性（因为它会解决并尊重你的包依赖项）。

对于test_require ，我承认我不确定这是否适合所有这些。 IIRC，它是setuptools的特定功能。 我们可以争辩说它是一组用于测试的抽象依赖项，并期望pipenv解决并安装那些然后执行pipenv install --dev的所有包，但我有一种感觉不太正确。 我对此以及围绕它的基本原理没有明确的想法或意见，抱歉。

我希望这一切都有意义。

@vphilippon你解释得很好，我想你已经说服了我。

TL;DR：在setup.py中指定抽象的、绝对必要的依赖关系，然后在Pipfile和Pipfile.lock中添加上下文（以及具体性），包括奇妙的"-e ." = "*"条目。

https://github.com/kennethreitz/pipenv/issues/209#issuecomment -337409290 的一个问题是，当我们想要将我们的应用程序部署到服务器时，我们没有获得可重现的环境。

我的意思是通常情况下，在开发将在其他项目中使用的_library_ 时，我们希望我们的install_requires非常松散（=不绑定到确切的版本）。 是的。 但是当我们构建一个 Web 应用程序（或任何应用程序）并将其部署在远程服务器或 docker 容器上时，我们可能需要固定的依赖关系。 即使我们在install_requires中指定了确切的版本，传递依赖项也不会被锁定，并且安装实际上可能会下载传递依赖项的不同（较新）版本，这可能会破坏您的部署。

（手动声明传递依赖的确切版本不是一个选项 - 太麻烦了。）

在这个用例中，我们应该依赖一个requirements.txt样式的锁文件（即使是传递依赖也可以指定确切的版本）。 但是，似乎 pipenv 不允许在pipenv lock -r中排除开发要求（例如pipenv lock --no-dev -r ），因此我们实际上可以制作这样的requirements.txt （然后可以读入install_requires )？

我将引用 Donald Stufft 的文章：

应用程序通常具有一组依赖项，通常甚至是一组非常复杂的依赖项，它已经过测试。 作为已部署的特定实例，它通常没有名称，也没有任何其他与打包相关的元数据。 这反映在 pip 需求文件的能力中。

换句话说：应用程序不是包。 该应用程序是环境，安装了一组具体的依赖项。 应用程序依赖项应由requirements.txt （或Pipfile / Pipfile.lock ）表示，而不是单个包install_requires 。

就个人而言，我什至会说全套固定依赖项（包括传递依赖项）应该在应用程序的requirements.txt中，而不是在包的setup.py中。 这概述了部署应用程序不是使用pip install myapp==1.0.0完成的想法，而是使用pip install -r requirements.txt （或pipenv install使用Pipfile.lock ），其中requirements.txt包括myapp==1.0.0以及所有其他依赖项和传递依赖项，固定。
看起来我走得有点远，但我已经在部署的“应用程序”由一组包驱动的环境中工作。 没有一个包可以代表应用程序本身，所以“包不是应用程序”的概念很早就被抛到了我的脸上😄。

我有一种强烈的感觉 Pipenv/Pipfile/Pipfile.lock 遵循这个想法。
这就是为什么从Pipfile.lock到setup.py的install_requires似乎存在差距的原因：无论如何，它真的不应该这样做。

@maintainers我希望您在此处输入以了解这是否确实您是如何看待这一切的。 我一直在宣扬我们应该如何对待依赖关系的愿景，但我也不想代替你说话。

@vphilippon我认为有不同的观点和术语。 但最终，我们想要安装一个固定依赖项列表。 因此，带有固定版本的requirements.txt （或具有此类声明依赖关系的包，并不重要）。 问题是，如何实际制作这样的文件？

使用pip-compile （来自pip-tools ），我可以从requirements.in编译这样的requirements.txt $ ，它将仅包含我的应用程序需要的非开发依赖项。 我不确定我是否正确解释了您的回复-您真的是说我们应该手动维护固定的依赖项requirements.txt （也稍微复制setup.py中已有的内容），也适用于传递依赖？ 这不可能是解决办法...

如果有pipenv lock --no-dev -r ，我认为这将解决这个问题。

@tuukkamustonen很抱歉造成混淆，我实际上只是在解决install_requires与requirements.txt / Pipfile / Pipfile.lock的想法。

因此，带有固定版本的 requirements.txt（或具有此类声明依赖项的包，并不重要）。

我认为区别非常重要，但正如你所说，这里有不同的观点。 让我们暂时同意不同意。 作为旁注，如果有地方继续讨论这个主题而不会给特定问题增加噪音，那就太好了。 这是需要在社区中进行更多讨论和分享的东西，IMO。

但是，似乎 pipenv 不允许在 pipenv lock -r 中排除开发要求

但最终，我们想要安装一个固定依赖项列表。 [...] 问题是，如何实际制作这样的文件？ [...] 使用 pip-compile (of pip-tools)，我可以从 requirements.in 编译这样的 requirements.txt，它将只包含我的应用程序需要的非开发依赖项。

啊，我一开始跳过了那部分，对不起。 看来你是对的：我无法找到一种方法来说pipenv install --not-dev-stuff （我很确定有一个，但很奇怪），并生成一个非开发环境。 那么有一个2个单独的部分有什么意义呢？ 那时我可能会遗漏一些东西，这与setup.py的用法无关。 也许它值得在一个新问题中讨论。

编辑：
我在这里犯了一个错误。 我确实没有找到在没有开发包的情况下生成Pipfile.lock的方法，但是，在新环境中，使用现有的Pipfile / Pipfile.lock ，做pipenv install不安装开发包。 这并不能解决@tuukkamustonen的观点，但是当我说无法安装“产品环境”时我错了，这是我的错误。

唷，有很多东西要赶上。

除非我弄错了，否则如果您正在构建一个轮子（=binary dist），则可以安全使用 #209（注释）中的代码，但如果您正在构建 sdist（=source dist）则不能使用。

@tuukkamustonen这仅用于在独立脚本中进行部署，请勿将其包含在 setup.py 中。 这是几个月前我们有pipenv lock -r之前的一个半hacky解决方法。 这种方法将适用于您拆分packages和dev-packages的用例。

我个人使用（3）（参见#209（评论）），直到 Pipfile 成为一个更通用的标准，此时我的任何项目都不会直接依赖于 Pipenv 代码，因为 Pipenv 似乎显然意味着用于管理基于 Pipfile 的 virtualenv 的工具，不一定是 Pipfile 库本身。

@elgertam似乎您的意见自此评论以来可能已经动摇了，但我会注意到将pipenv与您的项目捆绑在一起可能不是一个好主意。 没有什么明确禁止这样做的，但是我们做了很多路径修补，这样使用时很容易引起问题。 我想我会用“使用风险自负”的警告来包装它。

维护者 我希望您能在这里输入，以了解您是否确实看到了这一切。 我一直在宣扬我们应该如何对待依赖关系的愿景，但我也不想代替你说话。

我认为您非常符合我们对项目长度的愿景。 感谢您编译所有这些并很好地表达了@vphilippon！

看起来本次讨论的其他相关部分已移至#942，所以我认为我们在这里很好。 如果我没有解决任何问题，请 ping 我。

我在https://github.com/pypa/pipfile/issues/98中跟进了一个具体的建议，我相信它为我们提供了一些可操作且实用的东西，可以改进 DX 以维护 Python 库。

想法？

import json, jmespath

install_requires = []
with open('Pipfile.lock') as f:
    context = json.loads(f.read())
    install_requires.extend(map(
        lambda n, v : n + v,
        jmespath.search('default | keys(@)', context),
        jmespath.search('default.*.version', context),
    ))

setup(
    name='foobar',
    packages=find_packages(),
    setup_requires=['jmespath'],
    install_requires=install_requires,
)

@cornfeedhobo我的理解是 setup_requires 不能很好地与 pip 配合使用。 您能否详细说明您建议如何使用此示例？

除非您先安装 jmespath，否则该示例将不起作用，因为 setup.py 被评估为普通 Python 代码。 setup_requires参数实际上并没有实现任何效果：如果程序达到那么远，则保证会安装 jmespath。

我在另一个问题中提到了这一点，但无法在 atm 找到它（整个问题跟踪器中重复的讨论太多了，再也找不到任何东西了），所以我再说一遍：请不要放置任何未构建的内容-在 setup.py 里面，除非你提供了适当的后备，或者有一个完美的理由。 包含上述setup.py的包甚至无法与安装在 virtualenv 中的 jmespath 的 Pipenv 一起使用； Pipenv 在干净的环境中调用setup.py egg_info ，将无法执行 jmespath 导入。 这是不好的做法。 请避免它。

@epot我不知道

@uranusjr感谢您提供经过深思熟虑的详细答案。 我只是在探索整个问题，所以我可能会更尴尬。 我也在跟踪 pypa/pipfile#98

如果我们不需要jmespath怎么办？

import json


install_requires = []
tests_require = []

with open('Pipfile.lock') as fd:
    lock_data = json.load(fd)
    install_requires = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['default'].items()
    ]
    tests_require = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['develop'].items()
    ]

@mschwager您不想固定版本，否则用户将遇到困难。 #1921 是一个使用==的库的示例，它最终会破坏用户的构建。

我很抱歉，但是使用setup.py以将其用作包或requirements.txt / Pipfile管理所述包的依赖项之间有什么区别？ setup.py和requirements.txt / Pipfile之间所需的库必须相同，对吗？ 因此没有理由不整合Pipfile 。 setup.py已经解析requirements.txt 。 为什么它不能解析Pipfile ？

摆脱requirements.txt并使用Pipfile会很棒

不，没有理由他们_必须_是相同的。 这是一个相当激进的假设，社区中的许多人会要求不同。

然而，确实有它们_可以_相同的原因。 Pipenv 不排除这一点。 它超出了范围，并且不受此项目的支持。 您完全可以构建一个库来支持它，并利用 pip 10.0 中实现的PEP 518来提供构建时支持。

正如您所说，没有理由不允许 setup.py 解析 Pipfile。 我期待着你做到这一点:)

了解有些人喜欢 setup.py 的抽象库，但这不是必须的吗？ 我的意思是，golang 仅具有具体的要求，但仍然能够仅仅因为它与名称匹配而用您自己的 fork 替换所需的库？ 可以理解的是 setup.py 集成不在范围内。

但是，看看 pipenv 的长期路线图是什么会很有趣。 很高兴看到它成为 Python 中的首选工具。 例如，以某种方式替换 setup.py 或为用户生成适当的 setup.py，无论哪种方式 pipenv 作为事实上的包管理器都很棒。 只是想知道是否有可能将范围扩展到包括 setup.py？

如果 pipenv 像 npm 等，那么他们的 package.json 允许远程安装，没有理由 pipenv 不能交互或替换 setup.py，使其在范围内。 我说得通还是听起来像是在服用疯狂的药丸？

谢谢你认为它是必须的。 鉴于您认为它如此重要，我相信我们将能够立即运行基于 Pipfile 的构建系统。