从 pyenv-virtualenv 切换到 pipeenv 时保持相同的共享虚拟环境

问题描述

我开始研究 pipenv 并且它似乎很不错.我唯一担心的是，我的大部分项目都涉及 numpy、scipy 和其他一些不那么小的库.

I started looking at pipenv and it seems to be pretty good. My only concern is, that most of my projects involve numpy, scipy and some other not-so-small libraries.

目前管理我的项目的方式:我已经安装了 pyenv 和 pyenv-virtualenv.我有几个(目前是 4 个)特定的 virtualenvs，每个都迎合了一个类型的项目.项目本身设置了 .pyenv-version，我启用了 pyenv 的自动加载 virtualenv 功能.如果我需要共享一个项目，我会从 virtualenv 生成一个带有 pip freeze -l 的 requirements.txt.

The current way manage my projects:I have pyenv and pyenv-virtualenv installed. I have a few (currently 4) specific virtualenvs that each cater to a type of project. The projects themselves have .pyenv-version set, I have the autoload virtualenv feature of pyenv enabled. If I need to share a project, I generate a requirements.txt with pip freeze -l from the virtualenv.

所以在我当前的设置中，我有 X 个项目和 Y，Y <<个virtualenvs，总共有几GB的硬盘空间.请注意，由于像 numpy 这样的大型库，每个 virtualenvs 都非常大，大约 700-900 MB.

So in my current setup, I have X number of projects and Y, Y << X number of virtualenvs, all amounting to a few GB of harddisk space. Note that because of large libraries like numpy each of the virtualenvs are pretty big, around 700-900 MB.

我的问题:

据我所知，pipenv 默认会为我的所有项目创建一个 virtualenv，所以我的 virtualenvs 会大大增加.我感兴趣的是:

As far as I understand, pipenv will, by default create a virtualenv for all of my projects, so the harddisk space taken up by my virtualenvs would increase considerably. What I'm interested in is:

• 是否可以在多个项目之间共享 pipenv 环境，完全使用相同的依赖项?即多个 pipenv 配置加载相同的 virtualenv?
• 如果没有，是否可以从我用 pyenv 设置的 virtualenv 生成 pipenv 配置文件?即我不会使用 pipenv 来实际运行我的项目，我不会使用 pipenv 创建任何 virtualenvs，但我会创建 pipenv 用于共享项目的配置文件(在这种情况下，可能还与 requirements.txt 一起).

• is it possible to share pipenv environments across several projects, that use exactly the same dependencies? i.e. multiple pipenv configs that load the same virtualenv?
• if not, is it possible to generate pipenv config files from a virtualenv I set up with pyenv? i.e. I would not use pipenv to actually run my projects, I would not create any virtualenvs with pipenv, but I would create pipenv config files for sharing the project (in this case, probably along side a requirements.txt as well).

编辑:我重写了大部分问题以使其更清楚.

edit:I rewrote most of the question to make it clearer.

推荐答案

pipenv 似乎不太适合您的特定工作流程，因为它以项目为中心而不是环境- pipenv 将虚拟环境视为易变的，并保留在情况需要时自由更改它的权利.您可以使用它，但在更改环境的情况下，由于 pipenv 更严格的审查，保持所有项目同步将很痛苦.

pipenv doesn't seem to be a good fit for your specific workflow because it's project-centric rather than environment-centric. pipenv treats a virtual environment as volatile and reserves the right to alter it freely if circumstances call for it. You can use it but in the case of alterations to your environments, it will be a pain to keep all projects synchronized due to pipenv's stricter scrunity.

您可以为pipenv明确指定一个用于项目的虚拟环境通过在项目根目录中创建一个带有路径的 .venv 文件(通常，virtualenvs在特定位置使用自动生成的名称创建，其中包含项目路径的哈希值).这似乎没有记录.

You can explicitly specify a virtual environment for pipenv to use for a project by creating a .venv file in the project root with a path to it (normally, virtualenvs are created in a specific location with autogenerated names that include a hash of the path to the project). This seems to be undocumented.

然而，pipenv 与 virtualenv 不同，它会检查并强制虚拟环境具有满足 Pipfile 和生成的 Pipfile.lock 中指定的确切上次测试配置".

However, pipenv, unlike virtualenv, checks and enforces that the virtual environment has the exact set of modules satisfying conditions in Pipfile and the exact "last tested configuration" specified in a generated Pipfile.lock.

• 此外，如果您从 requirements.txt 生成 Pipfile，它将指定确切的包版本并包含所有依赖项 -- 虽然按照设计，它应该包含更多智能信息.

• Besides, if you generate Pipfile from requirements.txt, it will specify exact package versions and include all dependencies -- while by design, it's supposed to contain more intelligent information.

因此，如果您更改环境中的任何软件包版本，您需要:

So, if you change any package version in an environment, you'll need to:

• 更新受影响项目中的所有Pipfile.lock(例如，复制更改的项目).使用生成的 Pipfile，您可以避免删除它们.
• 如果有更改，请将受影响项目中的所有 Pipfile 更新为新的包版本(例如，复制更改的版本)

• update all Pipfile.locks in affected projects (e.g. copy the changed one). With a generated Pipfile, you may get away with deleting them instead.
• update all Pipfiles in affected projects to the new package versions (e.g. copy the changed one) if there was a change

这篇关于从 pyenv-virtualenv 切换到 pipeenv 时保持相同的共享虚拟环境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！