pipenv当您要在多个平台（即 Windows、Linux 和 Mac）上开发和运行应用程序代码时，是否有用于确定性构建的最佳实践？
例如，如果您在基于 Windows 的 Python 环境中安装，则要求pytest将atomicwrites库定义为条件依赖项pytest。
但是，如果我定义...
[dev-packages]
pytest = "*"
作为我的项目中的要求Pipfile并运行pipenv install --dev以Pipfile.lock在基于 Linux 的 Python 环境中生成我的初始文件，然后atomicwrites在结果Pipfile.lock文件中既未安装也未以任何方式指定。
稍后，在我git commit生成新的 Linux之后Pipfile.lock，我或其他人最终会将提交的Pipfile.lock文件拉到他们的 Windows 机器上，并运行pipenv install --dev以生成他们自己的本地pipenv环境。
但是，当他们去运行pytesttest-runner 时，它会失败，因为atomicwrites他们的pipenv环境中没有安装，因此pytest命令会因为缺少依赖项而失败。
更重要的是，当使用像 GitHub Actions 或 Azure Pipelines 这样的 CI 服务时，我的 Windows 测试构建也会失败，因为pipenv也无法在atomicwrites那里安装依赖项（因为它不会在 repo 的Pipfile.lock规范中指定）。
这个pytest例子是这个问题的一个超级简单的例子。在这种情况下，只需将其atomicwrites作为我的[dev-packages]要求之一添加到我的要求中就足够容易了，Pipfile以便无论平台如何都可以安装它，或者甚至添加sys_platform = "== 'win32'"以指定它只能pipenv在 Windows 平台上安装。
然而，当我的项目有许多依赖项时，这些平台条件依赖项变得更难处理，所有依赖项都有自己的平台条件依赖项。
但是，我还没有找到任何直接的方法来处理这个问题（pipenv除了在不同平台上Pipfile.lock运行之前不使用或删除文件pipenv install --dev）。
是否有任何pipenv用户有处理此多操作系统Pipfile.lock安装问题的推荐最佳实践？
这显然为时已晚，对您没有帮助，但我发现在这些多个环境中生成锁定文件同时保留过时的版本可以解决 pipelinev 的大部分问题。
例如，我们的 CI/CD 使用 GitHub 图像，因此在 Linux shell 的 Windows 子系统中：
pipenv install --dev
然后，在 Windows shell 中
pipenv install --dev --keep-outdated
但是，在 Windows 中运行有时可能会依赖于该平台（在撰写本答案时，colorama 目前正在执行此操作）。为了避免这种情况，您可以在 WSL 中重新生成锁定文件：
pipenv lock --dev --keep-outdated
这将使“过时的”包保留在仅限 Windows 的环境中，但通常会修复平台条件。
请注意，上面的舞蹈最终并不是万无一失的——我发现这个问题是因为这个确切的方法不适用于atomicwrites. 但是，它似乎可以解决绝大多数问题，而那些通常无法通过手动将包添加到依赖项中来解决的问题。