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

Question

我正在建立一个python项目，使用一个Anaconda虚拟环境。我正在生成一个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模块）。

第一眼看到，在virtualenv（pip install -r requirements-conda.txt）上的项目中导入conda生成的requirements.txt会引发以下错误：

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

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

Answer 1

I'm setting up a python project, using an Anaconda virtual environment. I was wondering though, when other developers want to contribute to the project, but want to use virtualenv instead of Anaconda, can they do that?

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

.
├── README.md
├── app
│   ├── __init__.py
│   ├── static
│   ├── templates
├── migrations
├── app.py
├── environment.yml
├── requirements.txt

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

environment.yml

So apparently both outputs are different, and my theory is: once I generate my requirements.txt with conda on my project, other developers can't choose virtualenv instead - at least not if they're not prepared to install a long list requirements by hand (it will be more than just the aiohttp module of course).

为了克服这个问题，我们使用了两个不同的环境文件，每个文件都有各自不同的格式，允许其他贡献者选择他们喜欢的文件。如果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

Am I right when I think that if developers would like to do this, they would need to programmatically change the package list to the format that virtualenv understands, or they would have to import all packages manually? Meaning that I impose them to choose conda as virtual environment as well if they want to save themselves some extra work?

建议（和常规）的方法是通过requirements.txt更改为pip理解的格式。激活您的环境（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

完整的讨论超出了这个答案的范围，但是similar questions值得一读。

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应用服务。假设您有一个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在通知您/repo所有者之前，让它的漏洞检测发现任何问题，也会给您额外的安心。这是一个很大的价值，免费的优点，有这个额外的依赖文件（小价格支付）。

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