Pythonデプロイのベストプラクティス - 複数のバージョン、標準インストール場所、パッケージツールなど

Question

この質問のさまざまな側面に関する多くの記事がありますが、すべてをまとめた記事は見ていません。

最初の主観的なステートメント：インタプリタの外に出て配備の問題を取り上げるときに、Python言語を使って作業するときのシンプルさが分かるようです。同じマシンに複数バージョンのPythonをインストールするにはどうすればよいですか？パッケージはどこにインストールする必要がありますか？ Disutils対setuptools対pipなどPythonのZenが展開に関してかなりひどく悪用されているようです。私はWindows上での "DLL hell"エクスペリエンスの不気味なエコーを感じています。

専門家は、これらの質問に関するある程度のベストプラクティスについて同意していますか？

複数のバージョンのPythonを同じマシンで実行していますか？どのように共存できると自信を持っていますか？新しいバージョンは、以前のバージョン（たとえばOSベンダーが提供するスクリプト）に依存する他のプロセスの前提を壊さないでしょうか？これは安全ですか？ virtualenvで十分ですか？

ローカルファイルシステム上のPython環境（サードパーティパッケージを含む）のさまざまなコンポーネントの場所に最適な選択肢は何ですか？ UnixyとWindows OSの多くの異なるバージョンの場所間に厳密な対応がありますか？

沼のmurkiestコーナー - どのようなインストールツール（setuptools、distutils、pipなど）を使用し、ファイルの場所、Python仮想環境、Pythonパスなど、あなたの選択にうまくいきますか？

これらは難しい質問のようです。私は、経験豊富なPythonistasがこれらの課題に対して標準的なアプローチ（あるいは2つ）を定義していることを期待しています。自信を持って使用できるシステム（別々の無関係なツールのように感じることの少ないシステム）として「一緒にハングアップする」アプローチは非常に役に立ちます。

Answer 1

これはかなり広い質問であると私は同意しますが、とにかく多くの部分に対処しようとします。

あなたの主観的なステートメントについて：Pythonのシンプルさと優雅さが、パッケージングと展開の問題が突然単純なものになることを意味する理由はわかりません。パッケージングに関連するものは単純ですが、他のものはそうではありません。完全で丈夫で簡単なパッケージングシステムを1つ持っていればユーザーにとっては最適ですが、それはそんな風にはなっていません。 distutilsが作成されて開発が中断され、setuptoolsが作成され、新しい解決策や新しい問題が追加され、社会問題のためにsetuptoolsから配布され、最終的にdistutils2が作成され、（More on Differences between distribute, distutils, setuptools and distutils2?）状況は開発者やユーザーにとって理想的ではありませんが、私たちはより良いものにするために取り組んでいます。

複数のバージョンのPythonを同じマシンにインストールするにはどうすればよいですか？現代のOSを使用している場合はパッケージマネージャを使用し、UNIXの場合はソースからコンパイルする場合は "make altinstall"を使用するか、Windowsのソースからコンパイルする場合は同様の非競合インストール方式を使用してください。 Debianユーザとして、私は "pythonX.Y"を使って個々のバージョンを呼び出すことができ、デフォルトバージョン（ "python"と "python3"）はDebian開発者が決定するものです。いくつかのOSがpython == python2という前提を壊し始めているので、それを祝福するか非難するために進行中のPEPがあります：http://www.python.org/dev/peps/pep-0394/ WindowsはPythonバージョンをデフォルトとして使用する方法がないようですので、別のPEPがあります：http://www.python.org/dev/peps/pep-0397/

パッケージはどこにインストールする必要がありますか？ distutilsを使用して、自分のサイトのパッケージディレクトリにプロジェクトをインストールできます（PEP 370またはdocs.python.orgを参照）。何が問題なのですか？

同じプロジェクトの異なるバージョンのパラレルインストールはサポートされていません。輸入システムとパッケージングツールの変更点について話し合うには、PEPが必要です。誰かがその議論を始める前に、virtualenvまたはbuildoutを使って十分にうまくいく。

「Python環境のコンポーネント」の場所についての質問は分かりません。

ほとんどの場合、システムパッケージを使用しています（DebianのAptitudeパッケージマネージャを使用しています）。プロジェクトを試すために、私は彼らのリポジトリをクローンします。 Aptitudeで利用できないものが必要な場合は、自分のsite-packagesディレクトリにインストールします（またはrepoに.pthファイルを置く）。カスタムPYTHONPATHは必要ありませんが、PYTHONUSERBASEを使用してユーザーサイトのパッケージの場所を変更しました。私はsetuptools/distributeで魔法と卵のコンセプトが好きではないので、私はそれらを使用しません。私はvirtualenvとpipを1つのプロジェクトで使い始めました（彼らはカバーの下でsetuptoolsを使用しますが、私は私のグローバルPythonにsetuptoolsがないように私設インストールを行いました）。

Answer 2

この分野のリソースの1つは、Tarek Ziadeによる「Expert Python Programming」です。私はこの本の質について相反していますが、話題はあなたが注目しているものだけです。

Answer 3

私は、virtualenvが同じマシン上で複数の環境を構成して維持する唯一の信頼できる方法であることを発見しました。環境をパッケージ化し、別のマシンにインストールする方法としてもあります。

パッケージ管理の場合、私は常にを使用します。virtualenvでうまく動作します。また、gitリポジトリなどのさまざまなソースからパッケージを簡単にインストールおよびアップグレードすることができます。