私は、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を選択するように彼らに強いることを意味しますか?
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
コマンドの両方を実行することを確認するのと同じくらい簡単です。