使用conda生成的requirements.txt设置virtualenv [英] Set up virtualenv using a requirements.txt generated by conda

问题描述

我正在使用Anaconda虚拟环境设置python项目。我正在生成requirements.txt文件，以便其他人可以轻松地为该项目设置自己的虚拟环境。该项目，但想使用virtualenv代替Anaconda，他们可以这样做吗？

我尝试了以下操作：

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

   ＃该文件可用于创建环境，其使用方法如下： 
  ＃$ conda create --name< env> --file<此文件> 
  ＃平台：win-64 
   aiohttp = 2.3.9 = py36_0 
  异步超时= 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模块。 点冻结> requirements.txt 然后生成：

    aiohttp == 3.0.1 
  异步超时== 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了-至少如果他们不准备这样做，就不会选择virtualenv手动安装一长串需求（当然，不仅仅是aiohttp模块）。

首先，将conda生成的requirements.txt导入到virtualenv上的项目（ pip install -r requirements-conda.txt ）引发此错误：

 无效的要求：'aiohttp = 2.3.9 = py36_0'
 =不是有效的运算符。你是说==吗？ 
  

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

解决方案

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

是的-实际上这就是我的许多项目的结构。为了完成您想要的工作，这里有一个简单的目录，我们将使用它作为参考：

 。 
├──README.md 
├──应用程序
│├──__init__.py 
│├──静态
│├──模板
├──迁移
├──app.py 
├──environment.yml 
├──requirements.txt 
  

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

environment.yml

因此，显然两个输出都是不同的，我的理论是：一旦我在项目上生成了带有conda的requirements.txt，其他开发人员就不能选择virtualenv了-至少如果他们不准备长时间安装，至少不会这样。手动列出需求（当然，不仅仅是aiohttp模块）。

为了克服这一点，我们使用了两个不同的环境文件，每个文件都有各自不同的格式，允许其他贡献者选择他们喜欢的文件。如果亚当使用Conda来管理他的环境，那么他要做的所有工作都是从 environment.yml 文件创建的：

  conda env create -f environment.yml 
  

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

  conda env导出> environment.yml 
  

实际上，因为 conda env创建的环境文件export 命令可以处理环境的 pip 软件包和 conda 软件包，我们什至不需要有两个不同的过程来创建此文件。 conda env export 将导出您环境中的所有软件包，而不考虑它们是从哪个安装渠道安装的。还将在 environment.yml 中对此进行记录：

 名称：awesomeflask 
渠道：
-anaconda 
-conda-forge 
-默认
依赖项：
-appnope = 0.1.0 = py36hf537a9a_0 
-回拨= 0.1.0 = py36_0 
-cffi = 1.11.5 = py36h6174b99_1 
-decorator = 4.3.0 = py36_0 
-... 
  

requirements.txt

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

更改为 pip可以理解的格式的常规方法是通过 requirements.txt 。激活您的环境（源激活或 conda激活），然后：

 点冻结> requirements.txt 
  

Say Eve，项目贡献者之一希望从<$创建一个相同的虚拟环境c $ c> requirements.txt ，她可以：

 ＃使用点子
 pip install -r requirements.txt 
 
＃使用Conda 
 conda create --name< env_name> --file requirements.txt 
  

完整的讨论超出了此答案的范围，但是

这就像确保每次安装新依赖项一样简单，我们同时运行 conda env导出和点冻结> requirements.txt 命令。

I'm setting up a python project, using an Anaconda virtual environment. I'm generating a requirements.txt so other people can easily set up their own virtual environment for the project.

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?

I tried the following:

• I set up an empty project in an Anaconda environment and installed the aiohttp module. Then conda list --export > requirements.txt generates the following:

  # 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
  

• I set up an empty project in a virtualenv environment and installed the aiohttp module there too. pip freeze > requirements.txt then generates:

  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
  

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).

A first sight, importing the conda-generated requirements.txt in a project on virtualenv (pip install -r requirements-conda.txt) throws this error:

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

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?

解决方案

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?

Yes - in fact this is how many of my projects are structured. To accomplish what you're looking for, here is a simple directory that we'll use as reference:

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

In the project directory above, we have both environment.yml (for Conda users) and requirements.txt (for 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).

To overcome this, we are using two different environment files, each in their own distinct format allowing for other contributors to pick the one they prefer. If Adam uses Conda to manage his environments, then all he need to do create his Conda from the environment.yml file:

conda env create -f environment.yml

The first line of the yml file sets the new environment's name. This is how we create the Conda-flavored environment file. Activate your environment (source activate or conda activate) then:

conda env export > environment.yml

In fact, because the environment file created by the conda env export command handles both the environment's pip packages and conda packages, we don't even need to have two distinct processes to create this file. conda env export will export all packages within your environment regardless of the channel they're installed from. It will have a record of this in environment.yml as well:

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?

The recommended (and conventional) way to _change to the format that pip understands is through requirements.txt. Activate your environment (source activate or conda activate) then:

pip freeze > requirements.txt

Say Eve, one of the project contributor want to create an identical virtual environment from requirements.txt, she can either:

# using pip
pip install -r requirements.txt

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

A full discussion is beyond the scope of this answer, but similar questions are worth a read.

An example of 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
...

Tips: always create requirements.txt

In general, even on a project where all members are Conda users, I still recommend creating both the environment.yml (for the contributors) as well as the requirements.txt environment file. I also recommend having both these environment files tracked by version control early on (ideally from the beginning). This has many benefits, among them being the fact that it simplifies your debugging process and your deployment process later on.

A specific example that spring to mind is that of Azure App Service. Say you have a Django / Flask app, and want to deploy the app to a Linux server using Azure App Service with git deployment enabled:

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

The service will look for two files, one being application.py and another being requirements.txt. You absolutely need both of these file (even if they're blank files) for the automation to work. This varies by cloud infrastructure / providers of course, but I find that having requirements.txt in our project generally saves us a lot of trouble down the road and worth the initial set-up overhead.

If your code is on GitHub, having requirements.txt also give you extra peace of mind by having its vulnerability detection pick up on any issue before alerting you / repo owner. That's a lot of great value for free, on the merit of having this extra dependency file (small price to pay).

This is as easy as making sure that every time a new dependency is installed, we run both the conda env export and pip freeze > requirements.txt command.

这篇关于使用conda生成的requirements.txt设置virtualenv的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！