Python の依存関係地獄: 仮想環境とグローバル依存関係の妥協点? 質問する

私は様々な方法を試してきましたプロジェクトの依存関係を管理するこれまでのところPythonでは:

1. pip でグローバルのすべてをインストールする (スペースは節約できますが、遅かれ早かれ問題が発生します)
2. pip & venv または virtualenv (管理が少し面倒ですが、多くの場合は問題ありません)
3. pipenv と pipfile (venv/virtualenv よりも少し簡単ですが、遅く、一部のベンダーロックがあり、仮想環境は実際のプロジェクト フォルダーとは別の場所に隠れます)
4. パッケージおよび環境マネージャとしての conda (パッケージがすべて conda で利用できる限りは素晴らしいですが、pip と conda を混在させるのは少々面倒です)
5. 詩 - これは試したことがない
6. ...

これらすべて (1. を除く) の問題は、ハードドライブの容量がすぐにいっぱいになってしまうことです。私は開発者ではなく、日常業務で Python を使用しています。そのため、それぞれが独自の機能を持つ小さなプロジェクトが何百もあります。残念ながら、プロジェクトの 80% で「大きな」パッケージ ( numpy、、、など)pandasが必要です。典型的な小さなプロジェクトは、コードが約 1000 から 2000 行ですが、venv/virtualenv/pipenv に 800 MB のパッケージ依存関係があります。scipymatplotlib事実上私の HDD の約 100 GB 以上が Python 仮想依存関係でいっぱいになっています。

さらに、これらすべてを各仮想環境にインストールするには時間がかかります。私はWindowsで作業していますが、多くのパッケージはWindowsのpipから簡単にインストールできません。Shapely、、Fiona-GDALコンパイル済みのホイールが必要です。クリストフ・ゴールケこれは簡単ですが、ほとんどのワークフローが中断されます (例:pip install -r requirements.txtまたはpipenv installpipfile から)。パッケージの依存関係のインストール/更新に 40%、コードの作成に費やす時間は 60% しかないように感じます。さらに、これらのパッケージ マネージャーはどれもコードの公開とテストにはあまり役立たないため、他のツール (例: setuptools、、、tox... )が必要ですsemantic-release。twine

同僚と話しましたが、全員が同じ問題に直面しており、誰も本当の解決策を持っていないようです。ほとんどのプロジェクトで使用するパッケージなど、一部のパッケージをグローバルにインストールする方法があるかどうか疑問に思っています。たとえば、、、はnumpypippandasで、または でインストールされます。これらはscipy、頻繁に問題が発生することのない、よく開発されたパッケージです。もしそうなら、いずれにせよ、自分のプロジェクトですぐに修正したいと思います。matplotlibC:\Python36\Lib\site-packagescondaC:\ProgramData\Miniconda3\Lib\site-packages

その他のものはローカルの仮想環境フォルダーに配置されます。現在のワークフローを から に移動したいと思っていpipenvますconda。

このようなアプローチは、まったく意味があるのでしょうか? 少なくとも、最近は Python で多くの開発が行われており、おそらく私がまだ見ていない何かが出現したのでしょう。このようなグローバルとローカルが混在する環境でファイルを設定する方法、たとえば、メンテナンス方法や、setup.pyGitlab 、Github などを通じて開発プロジェクトを共有する方法についてのベスト プラクティス ガイダンスはありますか? 落とし穴や注意点は何ですか?requirements.txtpyproject.toml

また、この素晴らしいブログ記事Chris Warrick による、ほぼ完全に説明されています。

[2020年更新]

半年が経ち、Conda（ミニコンダ) は私の問題のほとんどを解決しました:

• WSL、Windows、ネイティブLinuxなど、あらゆるシステムで実行でき、conda env create -f myenv.ymlどのプラットフォームでも同じです。
• ほとんどのパッケージはすでにconda-forgeで利用可能であり、独自のパッケージをconda-forgeで受け入れてもらうのは簡単です。
• condaにないパッケージについては、pipconda環境にインストールして、pipを使用してpypiからパッケージを追加できます。ヒント：はconda update --all -n myenv -c conda-forgecondaからのパッケージのみを更新し、でインストールされたパッケージは更新しませんpip。pipでインストールされた依存関係は、を使用して手動で更新する必要がありますpip install pack_name --upgrade。condaでpipを使用してパッケージをインストールすることは、通常は緊急の解決策であることに注意してください。避けられた
• environment.ymlcondaチャンネルの優先度、condaからのパッケージ、pipからのパッケージを指定して、strictまたはopenを作成できます。
• これらのymlからconda環境を1つのステートメントで作成できます。たとえば、Gitlab Continuous Integrationで開発環境をセットアップするには、次のようにします。Miniconda3 Dockerこれにより、テスト実行が非常にシンプルで簡単になります。
• s内のパッケージ バージョンはyml、状況に応じて厳密またはオープンに定義できます。たとえば、env を Python 3.6 に固定し、このバージョン範囲 (例: 3.6.9) のセキュリティ更新を取得することができます。
• condaはWindowsのCコンパイル依存関係に関するほぼすべての問題を解決できることが分かりました。Windowsのconda envsは凍結Python コードを実行可能ファイル (テスト済み!) に変換し、何らかの理由でパッケージ マネージャーを使用できない Windows エンド ユーザーに配布できるようにします。
• 「大きな依存関係」の問題に関して: 最終的に、多くの特定の (つまり小さい) conda 環境と、いくつかの非特定の (つまり大きい) conda 環境を作成しました。たとえば、かなり大きな がありjupyter_env、そこに jupyter lab とほとんどの科学パッケージ (numpy、geos、pandas scipy など) がインストールされています。これらのツールにアクセスする必要があるときはいつでもこれをアクティブ化して、それらを 1 か所で最新の状態に保つことができます。特定のパッケージの開発用に、パッケージ依存関係にのみ使用する追加の環境があります (例packe1_env)。全体で約 10 個の環境があり、管理可能です。いくつかの汎用ツールは、基本の conda 環境にインストールされています (例 ) pylint。注意: pylint/pycodestyle/autopep8 などを (例) VS Code で動作させるには、python-code-dependencies を含む同じ環境にインストールする必要があります。そうしないと、未解決のインポート警告が表示されます。
• インストールしましたミニコンダとチョコレートWindows 用のパッケージ マネージャー。 で最新の状態に維持しconda update -n base conda、週に 1 回 envs を更新するとconda update --all -n myenv -c conda-forge、うまく機能します。
• 新しいアップデート：利用可能なフラグがあります--stack（現在2019-02-07) は、conda 環境を積み重ねることを可能にします。conda activate my_big_envこれにより、conda activate --stack dev_tools_envいくつかの汎用パッケージを多くの環境で利用できるようになります。ただし、注意して使用してください。pylint などのコード リンターは、リントされるコードの依存関係と同じ環境にある必要があることがわかりました。
• 新しいアップデート 2conda: (WSL)から使い始めましたWindows Subsystem for Linuxが、これによりワークフローが大幅に改善されました。パッケージのインストールが高速化され、WSL に直接接続された Windows で VS Code Insiders を操作できるようになり、Linux 環境での Python パッケージのバグが大幅に減少しました。
• もう一つのアップデートちなみに、ミニコンダドッカーローカルの conda env ワークフローをコンテナ化されたインフラストラクチャ (CI および CD) に完璧に変換できます。しばらくテストしましたが、かなり満足しています。conda は pip よりも多くの依存関係作業を管理するため、Dockerfile は Python Docker よりもクリーンです。最近では、たとえばコンテナ内から起動される jupyter lab で作業する場合などに、これをますます使用しています。
• はい、conda env 内の特定のパッケージ間の互換性の問題に遭遇したことがありますが、非常にまれです。2 つの方法があります。安定して動作する必要がある重要な env の場合は、 を有効にします。conda config --env --set channel_priority strictこれにより、互換性のあるバージョンのみがインストールされます。パッケージの組み合わせが非常に少なくまれな場合、解決できない依存関係の競合が発生する可能性があります (つまり、env を作成できません)。この場合、私は通常、実験的な開発用に、パッケージを少なくして(デフォルト)channel_priorityに設定する小さな env を作成します。 (ではなく) や(ではなく) などの、解決が容易なパッケージ サブセットが存在します。 では解決できない実験的な env の場合は、たとえば のPython の下位バージョンを試すのも良い方法です。最後の手段として、パッケージを pip でインストールします。これにより、conda のパッケージ リゾルバを回避できます (ただし、不安定な環境やその他の問題が発生する可能性があります。警告しました!)。最初に env に を明示的にインストールするようにしてください。flexiblegeoviews-coregeoviewsmatplotlib-basematplotlibstrictconda create -n jupyter_exp_env python=3.6 -c conda-forgepip
• 全体的な欠点は、大きなconda-forgeチャネルを使用するとcondaが遅くなることです。取り組んでいるしかし同時に、conda-forge インデックスは急速に成長しています。

[2021年更新]

この投稿はまだ多くの閲覧数を獲得しているため、2021 年の主観的なアップデートを次に示します。

• データサイエンスに携わっている方（ミニ）コンダまだ見る価値がある
• さもないと、詩そして、それはpyproject.toml共通の合意された分母であるように思われる

[2023年更新]

私は徐々に conda から離れつつあります。pip+ のvenv方がより実行可能なオプションのようで、多くの場合、より良く、より速く動作します (例: pytorch、transformers)。Windows は忘れてください。pip は WSL/Linux でのみ適切に動作します。パッケージ メンテナー向けに、 -only ベースのパッケージsetuptools>64が使用できるようになり、ついに統一されたパッケージ エクスペリエンスが実現しました。 'spyproject.tomlを取り除いてください。setup.py