複雑な問題に対するより簡単な解決策

Pythonで依存関係（dependencies）を管理するという課題は、多くの方々によって記述されてきました。 これは過去のもので、ウェブで矛盾する投稿が多く残っています。 最先端のベストプラクティスであっても、新しい依存関係（dependencies）を追加するときにDependency Hellで終わる可能性があります。依存関係を実装するために2013年に最初に報告された未解決の問題（open issue for pipです）があるため、通常の一連の回避策は、この関連XKCDのようになります：

Instacartでは、Loreのベストプラクティスを自動化しています。そのため、データサイエンティストとマシーンラーニング（機械学習）エンジニアは、Dependency Hellで時間を費やさずに、どのような環境でも、どのコンピュータでも自分の仕事を簡単に再現できます。 これにより、複数の人が1つのプロジェクトで共同作業を行い、あるプロジェクトから別のプロジェクトに簡単に切り替えることができます。 また、不注意のせいで、secondary dependenciesの変更によるランダムな生産に関しての問題も排除できます。

すべてのアプリケーションが独自のvirtualenvを持っていると、個々のコントリビューターには、企業のコードベース全体を最新バージョンに更新することなく、dependenciesの更新を確実に管理する権限が与えられます。 リリースから10年後、Python 2 vs 3の議論はまだ残っています。これは古いモノリシックコードベースが新しいプロジェクトに足を引っ張られるせいです。

Best Practices (in 2018)

• 1.ベストプラクティスに関しての作業はちゃんとコードを書いてください。
• 2.各プロジェクトに新しいvirtualenvを使用する
• 3.変更時にpip freeze > requirements.txt
• 4. runtime.txtに正確なPythonバージョンを指定する（明示する）
• 5.プロジェクトコードは、Pythonモジュールで編成する必要があります。

Lore’s open sourceは、環境変数の追加、PATHの更新、余分なコマンドの追加なしに、これらのステップを満たすために必要なすべての処理を行います。これは 現在の作業ディレクトリを使用する自然なワークフローです。インストールするのも簡単です：pip install lore

$ cd my_app $ lore python   # launch python in my_app's virtualenv $ lore pip      # my_app's pip $ lore console  # my_app's ipython (installed in virtualenv) $ lore notebook # my_app's jupyter notebook $ lore lab      # my_app's jupyter lab $ lore exec     # execute anything in my_app's virtualenv/bin/ $ lore env      # see what else is in there $ lore test     # you do have unit tests, don't you?

すべてのloreコマンドは、delegate（デリゲート）に余分な引数を渡します。 loreを使用すると、brew、apt-get、anaconda、miniconda、pipenv、pyenv、pyvenv、venv、virtualenvなどの組み合わせは必要ありません。Loreは軽量でモジュラー設計であり、アプリケーションの要件に他のエントリを追加しません 。そして一番重要な機能は“無駄なやり直しを防止するため”です。

____を使ってみないですか？

・brew、apt-get、その他のOSパッケージマネージャは、Pythonマイナーバージョンまたはパッチバージョンを仕分けすることを許可させないため、定期的にアップグレードする必要があります。

・Docker sortはOSイメージをフリーズすることでこの問題を解決しますが、これでもPythonや依存関係のバージョンの特定の制御はできません。

・Pyenvは複数のPythonバージョンを細かく制御できますが、パッケージの依存関係には対応できません。

・Pipfileはパッケージの依存関係の管理に頼れますが、まだ開発中です。 この技術が完全に成熟した場合（完成）には、これを代替手段として採用することはありますが、現時点ではrequirement.txtを使っています。

•autoenv、direnv、.venvなど、$ PATHやその他の環境変数を自動的に変更するものは、プロジェクトディレクトリにいるときにシステムのPython（およびパッケージ）へのアクセスを阻止します。＃！/ usr / bin / env python。

•Anacondaは大規模なインストールを必要とし、コードを扱う（唯一の）人ならば一元的な依存関係管理は素晴らしいですが、requirements.txtも使用しない限り、他の人があなたの仕事を引き継ぐのは難しくなります。つまり、pipは他のコントリビュータが実際にコラボレーションするために必要なすべてのものです。

・（pyenv + virtualenv + pip）や（miniconda + environment.yml）は、実行可能な最小限の製品と見なされますが、実際にそのベストプラクティスを知り、一貫して使用している人々に依存しています。 多くの人々は、率直に、より大きなものに関心を持つので、そうしないでしょうし、したくないでしょう。 これらのワークフローは、上級チームメンバーがフォローすべきです。

さらに、バージョンにパッチを適用するすべてのパッケージを凍結する必要があるかどうかについては、ニュアンスがあります。 もしバージョンをフリーズしなければ、アップストリームのすべての開発者から無償でアップグレードされることが期待されます。

実際には、時々不定期にcontinuous integrationパイプラインに導入されたバグや改ざんの変化に気付くはずです。それともプロジェクトをチェックアウトする次の開発者が、最も依存している依存バージョンを調べるのに30分かけて、ただ最適な依存関係バージョンを確認する。これらの破損の原因を追跡することは難しいです。なぜなら、それらはあなた自身のコードではなく、変更は追跡されず、意図的でもないからです。 Python自体のパッチバージョンの変更にも同じロジックが適用されます。

アプリケーション開発者ではなくライブラリ保守担当者が、他のライブラリとのダウンストリーム依存関係の競合を引き起こす可能性を減らすために、テストされた依存バージョンのホワイトリストの範囲に奨励されるべきであるというニュアンスがあります。

仕方は

任意のプロジェクトにこれらのベストプラクティスを使用する場合は、一回設定を完了するまでに約2分かかります。

# install lore $ pip install --upgrade lore # setup dependency managment $ cd my_app $ lore init . --bare --python-version=3.6.6 # 2 or 3, whatever # Ship it! $ git commit -a -m 'deep freeze dependencies' $ git push

新しいアプリケーションを作成している場合、init my_appはディレクトリmy_appをテンプレートからで作成します。既存のプロジェクトの足場の作成をスキップします。 Lore Appをチェックアウトした誰もが即座に馴染みのものとなります。 彼らがディレクトリに移動し、loreテストを初めて実行すると、すべての依存関係は、マシン上の新しい仮想環境にインストールされます。

Loreは、CIのテストとdeploymentのための信頼できるビルドも提供しています。 Pythonバージョンと仮想環境パッケージは、多くのプロジェクトで高速で効率的な再現性を得るために、マシンにキャッシュされたRussian Dollです。

loreをインポートすると、バージョンの不一致や要求を満たさない時があると、すべての依存関係が高速で失敗するかどうかがチェックされます。 開発環境またはテスト環境では、requirements.txtに新しい要件が自動的に追加され、CIパイプラインがプッシュダウンされます。

Loreは厳しいです。 あなたが手動で仮想環境の外部からPythonプロセスを起動し、Appのモジュールをインポートしようとすると、適切な依存関係を持つ正しい環境でPythonを再起動します。 微妙な依存関係のバグによって引き起こされる偽のエラーを追跡する時間を無駄にしてはいけません。

もちろん、これらはすべて環境変数、設定ディレクトリ、隠し.環境ファイル、Pythonコードで設定することができます。 我々はconfigurationより慣習を強く信じており、ルールは壊すべきものです。

Full disclosure（全面開示）

Loreの依存関係の管理は、pyenvがWindowsと互換性がないため、現在インストールされているシステムのPythonバージョンに限定(限られ)されています。 これを修正したいと思います。

Loreは、Pythonを仮想環境に再起動するため、アプリケーションの起動に数百ミリ秒を追加します。 その時が問題であれば、〜/ .pyenv / versions / 3.6.6 / envs / my_app / bin / loreのような適切なパスを使って、正確な仮想環境でloreを直接起動してください。 lore 環境でこのパスなどを見つけることができます。

あなたのシステムが記事の冒頭にXKCDのように見える場合は、すべてをアンインストールし、Brew Doctorの提案に従ってください。 Loreはクリーンアップなしでこれらの問題を回避しますが、実際のシステムを持っているといいです。 あなたが作業しているプロジェクトではなく、システム全体をインストールしたPythonスクリプトの場合でも、それを独自の仮想環境に押し込むことができます。

# install virtualenv
pip install virtualenv

# create a virtualenv
virtualenv ~/venvs/a_cool_project

# install your thing in its own virtualenv
~/venvs/a_cool_project/bin/pip install a_cool_project

# make the virtualenv installed executable available system wide
ln -sf ~/venvs/a_cool_project/bin/cool_runtime /usr/local/bin/cool_runtime

他にLoreがあなたの人生を楽にしてくれることができるかどうか気になりましたら、入門記事を読んでください：

タイトル：Freezing Python’s Dependency Hell in 2018
作者：Montana Low原文URL:https://tech.instacart.com/freezing-pythons-dependency-hell-in-2018-f1076d625241