是否有允许团队通过类似 git 的界面共享 venvs 的 python 包？答案

【问题标题】：Is there a python package that allows teams to share venvs through a git-like interface?是否有允许团队通过类似 git 的界面共享 venvs 的 python 包？
【发布时间】：2020-11-06 13:59:57
【问题描述】：

我正在与一个团队合作。我们每个人都有自己的 Windows 系统。我们有共享驱动器和共享 git 存储库。我们想要一个共享的虚拟环境（在 Python 中）。

我的理解（来自我自己和其他人之前的问题）是虚拟环境不包括运行 python 所需的所有文件，特别是共享 VE 不包括 Python 解释器。

我可以看到我们如何创建一个共享的 VE，似乎我们可以复制它，或者将它放在共享驱动器上，或者将它放在一个 git 存储库中。但我对此的理解是，它并没有消除个人安装自己本地版本的 python 的需要。对吗？

我的一位同事听说（或读到）“有一个包允许团队通过类似 git 的界面共享他们的虚拟环境配置。这样你可以“拉”更新的配置，它会安装自动新的包。这允许每个人在将其发布给团队之前更改配置并对其进行测试。”

那么有没有一个特殊的包来启用它？或者它只是与其他文件一起包含在 git 存储库中的常规 venv？如果我们这样做，那么我们必须将所有 venvs 放在文件系统中的相同位置，或者我们必须进入并手动更改 activate.bat 中的 VIRTUAL_ENV 变量。对吗？

无论如何，我们都必须安装我们自己的本地版本的 python。对吗？

【问题讨论】：

如果 virtualenv 在共享驱动器上，那么每个人都可以访问它。您只需确保它位于共享用户目录中，并且是组可读。虚拟环境有自己的python可执行文件，激活后在虚拟环境中运行which python就可以看到。
@RoadRunner 和@DanielFarrell 所说的应该是您的主要指导方针。在 Google Drive、其他一些云存储上共享 venv 的当前状态，或者甚至将其全部推送到某个 git 上似乎是更简单的选择。
@Apollo 在这种情况下，venvs 是独立的吗？每个人还需要在自己的机器上安装某些版本的 python 吗？
@RoadRunner 现在只用我自己进行测试，然后再打扰其他人。我安装了最新的 pycharm 和 python3.85 venv。我在 C:（本地）和共享驱动器上有一个 venv。当我运行该程序时，它可以使用共享版本正确运行。（Pycharm 告诉我它在使用什么。）但是当我点击 Open Terminal 时，它继续使用 C: 驱动器版本，尽管我将 Project->Interpreter 和 Console->python 控制台都设置为使用共享版本。跨度>
@elbillaf Venvs 有自己的 python exe。

标签： python git package virtualenv

【解决方案1】：

如果虚拟环境位于共享驱动器上（组可读），那么您的团队成员应该能够访问它。虚拟环境只是一个目录。

但我对此的理解是，它并没有消除个人安装自己的本地 python 版本的需要。对吗？

虚拟环境有自己的python二进制文件，激活后在虚拟环境中运行which python就可以看到。

那么有没有一个特殊的包来启用它？或者它只是与其他文件一起包含在 git 存储库中的常规 venv？如果我们这样做，那么我们必须将所有 venvs 放在文件系统中的相同位置，或者我们必须进入并手动更改 activate.bat 中的 VIRTUAL_ENV 变量。对吗？

我建议不要将虚拟环境目录上传到版本控制，因为它包含不属于其中的二进制文件和配置文件。也没有必要这样做，因为依赖关系在 requirements.txt 文件中进行跟踪，该文件列出了 pip 依赖关系并提交给版本控制。另外，激活虚拟环境时，VIRTUAL_ENV环境变量会自动导出，无需修改。

结论

为简单起见，最好让每个用户创建自己的虚拟环境并在其本地计算机上安装来自requirements.txt 的依赖项。这还可以确保用户不会对会影响其他用户的虚拟环境进行更改，这是上述共享驱动器方法的缺点。

如果他们想要获取最新的需求，那么使用git pull 获取最新的更改并使用pip install -r requirements.txt 重新安装依赖项就足够了。您只需要确保激活虚拟环境，否则依赖项将在系统范围内安装。这就是pipenv 包也派上用场的地方。

通常在我的团队项目中，自述文件包含为每个团队成员获取此设置的说明。

此外，正如 cmets 中提到的 Daniel Farrell 很有帮助，pip 将无法在虚拟环境中管理像 libffi、openssl、python-devel 等包。这就是使用 Docker 容器变得有用的地方，因为您可以在构建在主机操作系统之上的隔离环境中安装依赖项。这可以确保依赖项不会与系统范围的包混淆，这是无论如何都要遵循的好习惯。

我过去用过的一个例子Dockerfile：

FROM python:3.8-slim-buster

# Set environment variables:
ENV VIRTUAL_ENV=/opt/venv
ENV PATH="$VIRTUAL_ENV/bin:$PATH"

# Create virtual environment:
RUN python3 -m venv $VIRTUAL_ENV

# Install dependencies:
COPY requirements.txt .
RUN pip install -r requirements.txt

# Run the application:
COPY app.py .
CMD ["python", "app.py"]

这是我从这篇Elegantly activating a virtualenv in a Dockerfile 文章中修改的。

【讨论】：

不使用 docker 的最大缺点是您的 pip 要求可能需要的系统包，但由于它们不是 python，它们不能来自 pip。我正在考虑 libffi、openssl 等。Docker 将其保存在 repo 中，但它超出了 virtualenv 或 pipenv 管理、iirc 的范围。一个很好的答案，无论如何

【解决方案2】：

容器化旨在解决“python从何而来？”问题。我的开发人员团队通常使用 Dockerfile 将他们的需求安装在 docker-compose 中，从而为他们的应用程序启动开发环境。与虚拟环境不同，容器提供了一个完整的用户空间解决方案，在 windows 和 osx 中运行良好。

【讨论】：