使用conda生成的requirements.txt设置virtualenv

Question

我正在使用Anaconda虚拟环境设置python项目。我正在生成requirements.txt，以便其他人可以轻松地为项目设置自己的虚拟环境。

我想知道，当其他开发人员想要为该项目做出贡献，但是想要使用virtualenv而不是Anaconda时，他们可以这样做吗？

我尝试了以下方法：

• 我在Anaconda环境中设置了一个空项目，并安装了aiohttp模块。然后conda list --export > requirements.txt生成以下内容：

  # This file may be used to create an environment using:
  # $ conda create --name <env> --file <this file>
  # platform: win-64
  aiohttp=2.3.9=py36_0
  async-timeout=2.0.0=py36hc3e01a3_0
  certifi=2018.1.18=py36_0
  chardet=3.0.4=py36h420ce6e_1
  multidict=3.3.2=py36h72bac45_0
  pip=9.0.1=py36h226ae91_4
  python=3.6.4=h6538335_1
  setuptools=38.4.0=py36_0
  vc=14=h0510ff6_3
  vs2015_runtime=14.0.25123=3
  wheel=0.30.0=py36h6c3ec14_1
  wincertstore=0.2=py36h7fe50ca_0
  yarl=0.14.2=py36h27d1bf2_0
  

• 我在virtualenv环境中设置了一个空项目，并在那里也安装了aiohttp模块。pip freeze > requirements.txt然后生成：

  aiohttp==3.0.1
  async-timeout==2.0.0
  attrs==17.4.0
  chardet==3.0.4
  idna==2.6
  idna-ssl==1.0.0
  multidict==4.1.0
  yarl==1.1.0
  

因此，显然两者的输出是不同的，我的理论是：一旦我在项目上使用conda生成了requirements.txt文件，其他开发人员便不能选择virtualenv了-至少如果他们不准备通过以下方式安装长清单要求（当然，不仅仅是aiohttp模块）。

乍看之下，将conda生成的requirements.txt导入virtualenv（pip install -r requirements-conda.txt）上的项目会引发以下错误：

Invalid requirement: 'aiohttp=2.3.9=py36_0'
= is not a valid operator. Did you mean == ?

我认为如果开发人员想要这样做，他们是否需要以编程方式将软件包列表更改为virtualenv可以理解的格式，或者他们必须手动导入所有软件包，对吗？意思是说，如果他们想节省一些额外的工作，我也让他们选择conda作为虚拟环境？

Answer 1

我正在使用Anaconda虚拟环境设置python项目。我想知道，当其他开发人员想要为该项目做出贡献，但是想要使用virtualenv而不是Anaconda时，他们可以这样做吗？

是的-实际上这就是我的许多项目的结构。为了完成您要寻找的内容，这是一个简单的目录，我们将其用作参考：

.
??? README.md
??? app
?   ??? __init__.py
?   ??? static
?   ??? templates
??? migrations
??? app.py
??? environment.yml
??? requirements.txt

在上面的项目目录中，我们同时具有environment.yml（对于Conda用户）和requirements.txt（对于pip）。

environment.yml

因此，显然两者的输出是不同的，我的理论是：一旦我在项目上使用conda生成了requirements.txt文件，其他开发人员便不能选择virtualenv了-至少如果他们不准备通过以下方式安装长清单要求（当然，不仅仅是aiohttp模块）。

为了解决这个问题，我们使用了两个不同的环境文件，每个文件都有各自不同的格式，允许其他贡献者选择他们喜欢的文件。如果Adam使用Conda来管理他的环境，那么他要做的全部工作就是从该environment.yml文件创建他的Conda ：

conda env create -f environment.yml

yml文件的第一行设置新环境的名称。这就是我们创建带有Conda风格的环境文件的方式。激活您的环境（source activate或conda activate），然后：

conda env export > environment.yml

实际上，由于该conda env export命令创建的环境文件可以处理环境的pip程序包和conda程序包，因此我们甚至不需要两个不同的进程来创建此文件。conda env export将会导出您环境中的所有软件包，无论它们是从哪个安装渠道安装的。还将记录以下内容environment.yml：

name: awesomeflask
channels:
- anaconda
- conda-forge
- defaults
dependencies:
- appnope=0.1.0=py36hf537a9a_0
- backcall=0.1.0=py36_0
- cffi=1.11.5=py36h6174b99_1
- decorator=4.3.0=py36_0
- ...

requirements.txt

我认为如果开发人员想要这样做，他们是否需要以编程方式将软件包列表更改为virtualenv可以理解的格式，或者他们必须手动导入所有软件包，对吗？意思是说，如果他们想节省一些额外的工作，我也让他们选择conda作为虚拟环境？

_更改为pip可以理解的格式的推荐（传统）方法是通过requirements.txt。激活您的环境（source activate或conda activate），然后：

pip freeze > requirements.txt

说夏娃，项目贡献者之一想从创建一个相同的虚拟环境requirements.txt，她可以：

# using pip
pip install -r requirements.txt

# using Conda
conda create --name <env_name> --file requirements.txt

完整的讨论超出了此答案的范围，但是类似的问题也值得一读。

一个例子requirements.txt：

alembic==0.9.9
altair==2.2.2
appnope==0.1.0
arrow==0.12.1
asn1crypto==0.24.0
astroid==2.0.2
backcall==0.1.0
...

温馨提示：永远创造 requirements.txt

通常，即使在所有成员都是Conda用户的项目中，我仍然建议同时创建environment.yml（供贡献者）和requirements.txt环境文件。我还建议尽早（最好从一开始）就通过版本控制对这两个环境文件进行跟踪。这有很多好处，其中一个事实是，它简化了调试过程和以后的部署过程。

我想到的一个具体示例是Azure App Service的示例。假设您有一个Django / Flask应用程序，并想使用启用了git部署的Azure应用服务将该应用程序部署到Linux服务器：

az group create --name myResourceGroup --location "Southeast Asia"
az webapp create --resource-group myResourceGroup --plan myServicePlan

该服务将查找两个文件，一个是application.py，另一个是requirements.txt。您绝对需要这两个文件（即使它们是空白文件）也能使自动化工作。当然，这随云基础架构/提供商的不同而不同，但是我发现requirements.txt在我们的项目中进行操作通常可以为我们节省很多麻烦，值得您进行初始设置。

如果您的代码在GitHub上，requirements.txt还可以通过在检测到任何问题之前通知漏洞或回购所有者，让您的漏洞检测更加安全。拥有这个额外的依赖文件（价格不菲）的优点是，免费具有很大的价值。

这就像确保每次安装新的依赖项时都运行conda env exportand pip freeze > requirements.txt命令一样简单。