condaによって生成されたrequirements.txtを使用してvirtualenvを設定する

Question

私は、Anaconda仮想環境を使用してpythonプロジェクトを設定しています。他の人がプロジェクト用に独自の仮想環境を簡単に設定できるように、requirements.txtを生成しています。

他の開発者がプロ​​ジェクトに貢献したいが、Anacondaの代わりにvirtualenvを使用したいとき、私はそれを行うことができますか？

私は以下を試しました：

• 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）このエラーをスローします：

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

開発者がこれを行いたい場合、パッケージリストをvirtualenvが理解できる形式にプログラムで変更する必要があると思いますか、それともすべてのパッケージを手動でインポートする必要があると思いますか？彼らが余分な作業を節約したい場合は、仮想環境としてcondaを選択するように彼らに強いることを意味しますか？

Answer 1

Anaconda仮想環境を使用してpythonプロジェクトをセットアップしています。ただし、他の開発者がプロ​​ジェクトに貢献したいが、Anacondaの代わりにvirtualenvを使用したい場合、それを行う？

はい-実際、これが私のプロジェクトの構成数です。あなたが探しているものを達成するために、参照として使用する簡単なディレクトリを次に示します。

.
├── 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モジュールだけではありません）。

これを克服するために、2つの異なる環境ファイルを使用しています。それぞれ独自の形式で、他の貢献者が好きなものを選択できるようにしています。 AdamがCondaを使用して自分の環境を管理する場合、environment.ymlファイルからCondaを作成するために必要なことはすべて次のとおりです。

conda env create -f environment.yml

Ymlファイルの最初の行は、新しい環境の名前を設定します。これが、コンダ風味の環境ファイルを作成する方法です。環境をアクティブ化（source activateまたはconda activate）してから：

conda env export > environment.yml

実際、conda env exportコマンドによって作成された環境ファイルは環境のpipパッケージとcondaパッケージの両方を処理するため、これを作成するために2つの異なるプロセスを用意する必要さえありませんファイル。 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が理解する形式に_changeするための推奨される（そして従来の）方法はrequirements.txtを使用することです。環境をアクティブ化（source activateまたはconda activate）してから：

pip freeze > requirements.txt

プロジェクトの貢献者の1人が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 App Serviceを使用してアプリをLinuxサーバーにデプロイしたいとします。

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

サービスは2つのファイルを検索します。1つはapplication.py、もう1つはrequirements.txtです。自動化を機能させるには、これらのファイルが両方とも（空のファイルであっても）絶対に必要です。もちろん、これはクラウドインフラストラクチャ/プロバイダーによって異なりますが、プロジェクトにrequirements.txtを含めると、一般的に、多くのトラブルを回避でき、初期設定のオーバーヘッドに見合う価値があることがわかります。

コードがGitHubにある場合、requirements.txtを使用すると、脆弱性の検出が問題を検出してから、/ repoの所有者に警告することで、さらに安心できます。これは、この追加の依存関係ファイル（少額の支払い）を持つメリットとして、無料で非常に大きな価値があります。

これは、新しい依存関係がインストールされるたびに、conda env exportコマンドとpip freeze > requirements.txtコマンドの両方を実行することを確認するのと同じくらい簡単です。