问题描述
我正在与团队合作。我们每个人都有自己的Windows系统。我们有共享的驱动器和共享的git存储库。我们希望有一个共享的虚拟环境（在Python中）。
我的理解（来自我自己和其他人的先前问题）是，虚拟环境不包括运行python所需的所有文件，尤其是共享的VE不包括Python解释器。
我看到了如何创建共享的VE，看来我们可以将其复制，或将其放在共享驱动器上，或将其存储在git存储库中。但是我对此的理解是，它并不能消除个人安装自己的本地python版本的需要。正确吗？
我的一位同事听说（或读过）“有一个软件包，使团队可以通过类似git的界面共享其虚拟环境配置。这样，您就可以“拉”更新的配置，它将安装该软件包。新软件包。这使每个人都可以更改配置并进行测试，然后再将其发布给团队。”
那么是否有特殊的软件包可以启用此功能？还是仅仅是git仓库中包含的常规venv以及其他文件？如果这样做，则必须将所有venv放在文件系统中的同一位置，否则我们必须进入并手动更改activate.bat中的VIRTUAL_ENV变量。正确吗？
无论如何，我们都必须安装我们自己的本地python版本。正确吗？
解决方法
containerization旨在解决“ python从何而来？”问题。我的开发人员团队通常使用Dockerfile将需求安装在docker-compose中，从而为其应用程序扩展开发环境。与虚拟环境不同，容器提供了一个完整的用户空间解决方案，可以在Windows和osx中很好地工作。
,如果虚拟环境位于共享驱动器（组可读）上，则您的团队成员应该可以访问它。虚拟环境只是一个目录。
但是我对此的理解是，它并不能消除个人安装自己的本地python版本的需要。正确吗？
虚拟环境具有自己的python二进制文件，在激活which python后在虚拟环境中运行时可以看到它们。
那么是否有特殊的软件包可以启用此功能？还是仅仅是git仓库中包含的常规venv以及其他文件？如果这样做，则必须将所有venv放在文件系统中的同一位置，否则我们必须进入并手动更改activate.bat中的VIRTUAL_ENV变量。正确吗？
我建议不要将虚拟环境目录上载到版本控制，因为它包含二进制文件，不属于该目录的配置文件。这样做也是不必要的，因为在requirements.txt文件中跟踪了依赖项，该文件列出了pip依赖项并提交给版本控制。此外，激活虚拟环境后，VIRTUAL_ENV环境变量将自动导出，因此无需进行修改。
结论
为简单起见，最好让每个用户创建自己的虚拟环境并将requirements.txt中的依赖项安装在其本地计算机上。这还可以确保用户不会对虚拟环境进行更改，而该更改会影响其他用户，这是上述共享驱动器方法的缺点。
如果他们想获取最新的要求，那么使用git pull来获取最新的更改并使用pip install -r requirements.txt重新安装依赖项就足够了。您只需要确保已激活虚拟环境，否则将在系统范围内安装依赖项。这就是pipenv软件包也很方便的地方。
通常在我的团队项目中，自述文件包含为每个团队成员进行此设置的说明。
此外，正如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文章中进行了修改。