いつものように、これはトレードオフであり、私は標準と予測可能性の側で間違っています。特に次のような単一目的の Python コンテナでは、次のことを痛感しています。パイソン:.*すべてをグローバルにインストールするか、またはコピー

以上サイトパッケージPython インストールの根幹から、またはPythonユーザーベース環境変数のようなものに/アプリ、そして使用しますpip install --userの代わりにピップインストール、 その後コピー以上それ。すべては、よりシンプルで、1 層の分離で十分であるという前提の下にあります。私は 1 つの分離層で十分であることに異論はありませんが、長年にわたって、運用環境では、単純さについて語るときに留意すべき点が複数あることに気づきました。全体的なテーマとして、私の目標はない

大手テクノロジー開発者の支持者がカンファレンスでそう言ったからといって、疑わしい見返りのために複雑さを増すいくつかの「ベストプラクティス」に無意識に従うこと。

しかし、私は考えることに多くの時間を費やしています副次的な効果私がやっていることの。私にとって、複雑さとはどれだけのキーを押さなければならないかということではなく、自分が行っていることの結果を推論することがいかに難しいかということです。そこで、私がまだ仮想環境を使用しており、将来も使用する予定である理由の不完全なリストを以下に示します。

予測可能性と親しみやすさ

それらの構造は明確に定義されており、単一の Python アプリケーションを保持できるように設計されています。

私は、以下を含むディレクトリ階層が気に入っています。

ビン、ライブラリ、 そして共有ディレクトリに保存され、デフォルトで自己完結型アプリケーションに最適な「コンテナ」になります。追加ファイル内の奇妙な設定ファイルなど、補助ファイルの保存が必要になります。等ディレクトリ。これらすべてが、何かに入れるのに最適です。/opt/アプリまたは/アプリ。

はい、10年前と違ってを使用すると、アプリケーションをシステム Python から分離する必要がなくなります。しかし、維持あなたの分離され、明確に定義された場所と構造にあるコードには、それ自体に価値があります。私は数十のサービスを担当しているので、感謝しています。

一貫性私が展開しているものすべてがそこにあることを知っていること/アプリそして、それが Python アプリケーションである場合、それが仮想環境であることがわかります。/app/bin/python, 仮想環境の Python を取得し、アプリケーションをインポートして実行する準備ができました。標準とコミュニケーション

この一貫性により、

チーム内およびチーム間のコミュニケーションより簡単に。デプロイメント成果物が仮想環境であると私が言う/文書化することが何を意味するかは誰もが知っています。そして、そうでないとしても、インターネットには、公式のもの。それはいつのようなものです黒コード スタイルについて考えたり議論したりするのをやめ、精神的なリソースをより重要なことに費やせるようになりました。¹。たとえ規格のすべてが気に入らないとしても、それが規格の究極の価値です。

そして仮想環境はPython のコア機能12年間2000 年代半ば以降の Python コミュニティの中核となる概念です。それは私たちが持っているものに最も近いものですPython で囲まれ、標準化され、よく理解されているアプリケーション ビルド アーティファクト。拡張された例えですが、私はこれらをコンパイル言語で動的バイナリをリンクした結果だと考えています。

使用できますローカルでを使用してデプロイできます。ディストリビューションパッケージ、できますDockerコンテナを使用してデプロイする。それは良い開発と運用で同じツールとプリミティブを使用します。それは、自分のツールを熟知し、心に留めておくべきことが少なくなることを意味します。したがって、別の方法を使用してアプリケーションをデプロイすると、明らかな利点が得られるはずです。

インポートの複雑さの崩壊

仮想環境の一般的な利点は、ローカルと Docker の両方で次のことができることです。関連する検索パスを絞り込むPython はインポートするコードを検索します。²。Python を実行する通過による隔離モード-私 これをさらに絞り込みます。

それで、もしa) グローバルには何もインストールしないでください³、そしてb) を使用します。パイソン仮想環境からのバイナリその間それを渡す-私、 あなた知る標準ライブラリにないものすべてしなければならない仮想環境にいる。これにより、Python のインポート動作がさらに強化されます。予測可能なインポートの問題のデバッグは殺人事件の謎ではありません。

それは私たちに次のことをもたらします...

ボーナスポイントは無視しても問題ないが、胸を痛める必要がある

地獄には私が感じているような怒りはないpip install --user。これは魅力的な迷惑行為であり、Python のパッケージングの悪い評判に大きなダメージを与えています。

主に、システム操作によるさらに悪い影響を隠蔽するために使用されます。サイトパッケージディレクトリ - Python インストールが壊れる最も一般的な原因です。すべてはユーザーローカルインストールを有効にするためのものです⁴、そもそもこれは悪い考えです。そういう意味では、npmproject-directory-local-first パッケージを備えたエコシステムは、古くて怠惰なやり方に囚われていた私たちのはるか先を行っていました。

最終的に、次の追加により、Python のインストールに関する推論がさらに複雑になりました。別の可動部分。ユーザーローカルの Python パッケージ内の奇妙なものによってバグトラッカーで誰かが私に怒鳴りつけるたびに 10 セントを持っていたとしたら、私はそうする必要はありません。スポンサーを懇願する。愛している限りPDM、私は毎日クトゥルフに感謝しています。PEP 582 /__pypackages__追加される可能性があるため拒否されました別の混乱のベクトル。プロジェクトローカルでの標準化.venvたとえそれが間違いなく正しい行動だったとしても、私仮想環境を中央の場所に保存することを好みました。

最後に：例えば、「一体なぜ？」

ここで具体的に解決しようとしている問題は何ですか?それは特別なツールや特別な概念ではなく、まさにそこにあります。標準ライブラリ、または使用しています紫外線すでに。と紫外線ベンブ、仮想環境の作成には、仮想環境の作成に比べて大幅に時間がかかりません。mkdir。彼らはそうかもしれないわずかにより大きなものですが、それらは実際に重要な意味を持っているのでしょうか？Python プロジェクトとそのすべての依存関係を扱いやすいディレクトリに分離するという 1 つの標準的な方法を避けても、何も簡単にはなりません。

仮想環境に対する抵抗のうち、どれだけが技術的な理由によるものではなく、Homebrew は Python の更新ごとにそれらを破壊しますDebian では、Python インストールが煩わしくアンバンドルされているため、使用するのが面倒になっています。

願っています紫外線その利便性とスピードは、人々の認識を変えるでしょう。

エピローグ

記事の冒頭で説明したショートカットは、次のような仮定に基づいています。サイトパッケージ場所と携帯性。彼らは次のような複雑さを導入しますpip install --user(これは Docker では意味的に奇妙であり、このような目的で使用されることを意図したものではありません)、開発で使用しているものと比べて、なじみのないツールやパラダイムが必要になる場合があります。ãããããããããããã¾

しかし私はあなたに何かをするように説得しようとしているわけではありません。私の理由のいくつかは目に見えない「雰囲気」側にあることを私は認識しています。これらのショートカットのパラメータの範囲内で、トレードオフに満足している場合は、何をしても自由です。しかし、それが決定的なものであることを示していただければ幸いですする一般的に Docker で仮想環境を使用するのは理にかなっています – それが理にかなっているかどうかあなた、のためのものですあなた決めること。私は毎回自分を弁護するのにうんざりしているので、ここできっぱりと自分の主張をします。

結局のところ、あなたはまだPython と Docker について私が言うことに興味があるなら、から始めることをお勧めします本番環境に対応した Docker コンテナ紫外線これは、私が Python アプリケーション用の Docker コンテナをできるだけ早く構築する方法を記録した生きたドキュメントです。

追伸私の尊い命の10周年を迎えるほぼその日にこれを出版することが信じられません。「virtualenv は生きています!」！多くのことが良い方向に変化しましたが、仮想環境は与え続けています。