[英]Best practice for using pipenv Pipfile and Pipfile.lock across multiple platforms
Is there a best practice for using pipenv
for deterministic builds when you're going to be developing and running application code on multiple platforms (ie Windows, Linux, and Mac)?当您要在多个平台(即 Windows、Linux 和 Mac)上开发和运行应用程序代码时,是否有使用pipenv
进行确定性构建的最佳实践?
For instance, the requirements for pytest
defines the atomicwrites
library as a conditional dependency if you are installing pytest
in a Windows-based Python environment.例如,如果您在基于 Windows 的 Python 环境中安装pytest
, 则atomicwrites
pytest
定义为条件依赖项。
However, if I define...但是,如果我定义...
[dev-packages]
pytest = "*"
as a requirement in my project's Pipfile
and run pipenv install --dev
to generate my initial Pipfile.lock
in a Linux-based Python environment, then atomicwrites
is neither installed nor specified in any way in the resulting Pipfile.lock
file.作为我项目的Pipfile
中的要求并运行pipenv install --dev
以在基于 Linux 的 Python 环境中生成我的初始Pipfile.lock
,然后在生成的atomicwrites
文件中既不安装也不以任何方式指定Pipfile.lock
。
Later, after I git commit
my new Linux-generated Pipfile.lock
, either I or someone else will eventually pull that committed Pipfile.lock
file down onto their Windows machine and will run pipenv install --dev
to generate their own local pipenv
environment.稍后,在我git commit
我的新 Linux 生成的Pipfile.lock
,我或其他人最终会将提交的Pipfile.lock
文件拉到他们的 Windows 机器上,并将运行pipenv install --dev
以生成他们自己的本地pipenv
环境。
However, when they go to run the pytest
test-runner, it will fail because atomicwrites
will not have been installed in their pipenv
environment, therefore the pytest
command will fail because of the missing dependency.但是,当他们 go 运行pytest
测试运行程序时,它将失败,因为atomicwrites
不会安装在他们的pipenv
环境中,因此pytest
命令将失败,因为缺少依赖项。
What's more, my Windows test-build will also fail when using a CI service like GitHub Actions or Azure Pipelines because pipenv
will fail to install the atomicwrites
dependency there too (because it will not be specified in the repo's Pipfile.lock
specifications). What's more, my Windows test-build will also fail when using a CI service like GitHub Actions or Azure Pipelines because pipenv
will fail to install the atomicwrites
dependency there too (because it will not be specified in the repo's Pipfile.lock
specifications).
This pytest
example is a super simple example of this issue.这个pytest
例子是这个问题的一个超级简单的例子。 In this case, it'd be easy enough just to add atomicwrites
as one of my [dev-packages]
requirements in my Pipfile
so that it gets installed regardless of the platform, or to even add sys_platform = "== 'win32'"
to specify that it should only be installed by pipenv
on Windows platforms.在这种情况下,只需在我的Pipfile
中添加atomicwrites
作为我的[dev-packages]
要求之一,以便无论平台如何都可以安装它,或者甚至添加sys_platform = "== 'win32'"
指定它只能由pipenv
在 Windows 平台上安装。
However, these platform-conditional dependencies become a much harder issue to deal with when my project has many dependencies, all with their own platform-conditional dependencies.但是,当我的项目有很多依赖项时,这些平台条件依赖项变得更难处理,所有依赖项都有自己的平台条件依赖项。
I've seen this issue discussed in a couple different locations, such as here , and here .我在几个不同的地方看到过这个问题,比如这里和这里。
However, I have yet to find any straightforward method for dealing with this (short of not using pipenv
or deleting the Pipfile.lock
file prior to running pipenv install --dev
on a different platform).但是,我还没有找到任何直接的方法来处理这个问题(在不同平台上运行pipenv install --dev
之前不使用pipenv
或删除Pipfile.lock
文件)。
Do any pipenv
users out there have a recommended best practice for dealing with this multiple-os Pipfile.lock
install issue?是否有任何pipenv
用户有推荐的最佳实践来处理这个多操作系统Pipfile.lock
安装问题?
This is obviously too late to be helpful to you, but I have found that generating the lock file in these multiple environments while keeping outdated versions resolves most of the problems with pipenv.这显然为时已晚,对您没有帮助,但我发现在这些多个环境中生成锁定文件同时保持过时版本解决了 pipenv 的大部分问题。
For example, our CI/CD uses GitHub images, so in a Windows Subsystem for Linux shell:例如,我们的 CI/CD 使用 GitHub 图像,因此在 Windows 子系统中 Linux Z2591C98B70119FE62E91898B:
pipenv install --dev
Then, in a Windows shell然后,在 Windows shell
pipenv install --dev --keep-outdated
However, running in Windows can sometimes pin a dependency to that platform (colorama currently does this as of this answer's writing).但是,在 Windows 中运行有时可以将依赖项固定到该平台(在撰写本答案时,colorama 目前正在执行此操作)。 To avoid that, you can regenerate the lock file again in WSL:为避免这种情况,您可以在 WSL 中重新生成锁定文件:
pipenv lock --dev --keep-outdated
This will keep the "outdated" packages from a Windows-only environment, but will generally fix the platform conditionals.这将使“过时”的软件包远离仅限 Windows 的环境,但通常会修复平台条件。
Note that the dance above is ultimately not foolproof--I found this question because this exact method was not working for atomicwrites
.请注意,上面的舞蹈最终并不是万无一失的——我发现了这个问题,因为这个确切的方法不适用于atomicwrites
。 However, it seems to resolve the vast majority of issues and those that cannot generally can be solved by adding the package to your dependencies manually.但是,它似乎可以解决绝大多数问题,而那些通常无法通过手动将 package 添加到您的依赖项来解决的问题。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.