使用 conda 生成的 requirements.txt 设置 virtualenv
Set up virtualenv using a requirements.txt generated by conda
我正在设置一个 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 作为虚拟环境？
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?
将pip 理解 的格式_change 的推荐（和常规）方法是通过requirements.txt。激活您的环境（source activate 或 conda activate）然后：
pip freeze > requirements.txt
比如说 Eve，项目贡献者之一想要从 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 环境文件。我还建议尽早（最好从一开始）就让版本控制跟踪这两个环境文件。这有很多好处，其中之一是它简化了调试过程和以后的部署过程。
spring 要记住的一个具体示例是 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 也会让您更加安心，因为它会在提醒您/回购所有者之前检测任何问题。这是一个很大的免费价值，因为有这个额外的依赖文件（付出的代价很小）。
这就像确保每次安装新的依赖项一样简单，我们 运行 同时使用 conda env export 和 pip freeze > requirements.txt 命令。
我正在设置一个 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 作为虚拟环境？
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?
将pip 理解 的格式_change 的推荐（和常规）方法是通过requirements.txt。激活您的环境（source activate 或 conda activate）然后：
pip freeze > requirements.txt
比如说 Eve，项目贡献者之一想要从 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 环境文件。我还建议尽早（最好从一开始）就让版本控制跟踪这两个环境文件。这有很多好处，其中之一是它简化了调试过程和以后的部署过程。
spring 要记住的一个具体示例是 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 也会让您更加安心，因为它会在提醒您/回购所有者之前检测任何问题。这是一个很大的免费价值，因为有这个额外的依赖文件（付出的代价很小）。
这就像确保每次安装新的依赖项一样简单，我们 运行 同时使用 conda env export 和 pip freeze > requirements.txt 命令。