Pythonパッケージのインストールについて最後に心配しなければならなかったのは、2年前、Enthought、NumPy、MayaVi2での作業でした。その経験は、非標準の場所（$HOME/usr/local2.6/たとえば）でPythonパッケージをインストールおよび更新するという風変わりな動作に関連する悪夢を長引かせました。
とにかく、私の仕事は私をさまざまなPythonパッケージのインストールに戻しています。CheeseShopチュートリアルでは、Buildoutに加えてDistUtilsとEasyInstallについて言及しています。これらの（および他の）PyPiインストールツールを比較する場所を見つけるのに苦労しているので、StackOverflowコミュニティを利用したいと思っています： 各インストールツールの長所と短所は何ですか？
まずは、インストールツールに関係なく、使い始めましょvirtualenv --no-site-packagesう！そうすれば、python パッケージはグローバルにインストールされず、古いプロジェクトや新しいプロジェクトに簡単に戻ることができます。
ここで、リストするツールは相互に排他的ではないため、比較は少しリンゴとナシです。ただし、Buildout は完全にお勧めできます。Python パッケージやその他のものをインストールし、(複雑な) プロジェクトのインストールと展開を自動化できます。
また、管理タスクを自動化する手段としてFabricを検討することをお勧めします。
Distributeはsetuptools（easy_install）の新しいフォークであり、これも考慮する必要があります。Guidoでさえそれをお勧めします。
ビルドアウトはパッケージングと直交しています---ビルドアウトはdistributeで使用できます。
すべてのプロジェクトでビルドアウトを使用することに決める前に、このトピックについて静かに少し調査しました（数週間の価値があります）。
Buildoutに加えてDistUtilsとEasyInstall！
これらすべてのツールを比較するための1つの場所を作成することの難しさは、それらがすべて同じツールチェーンの一部であり、予測可能で信頼性が高く柔軟なツールセットを作成するために一緒に使用されることです。
たとえば、easy_installは、distutilsパッケージをpypi（cheeseshop）からシステムのPythonのsite-packagesディレクトリにインストールするために使用されます。これにより、システム/グローバルsys.pathへのパッケージのインストールが大幅に簡素化されます。
easy_installは、すべてのプロジェクトで一貫性のあるパッケージに非常に便利です。しかし、プロジェクトが依存しないパッケージをインストールするために、システムのeasy_installを使用することを好むことがわかりました。たとえば、github-cliはすべてのプロジェクトで使用します。これにより、コマンドラインからプロジェクトのGithubの問題を操作できるようになります。私はこれをプロジェクトで使用しますが、これは便宜上のものであり、プロジェクト自体はこのパッケージに依存していません。
プロジェクトの依存関係を管理するために、私はビルドアウトを使用します。Buildoutを使用すると、プロジェクトが依存しているパッケージのバージョンを具体的に示すことができます。ビルドアウトは宣言型であるため、pip-requirements.txtよりもビルドアウトの方が好きです。pipを使用してパッケージをインストールし、開発の最後にrequirements.txtファイルを生成します。一方、Buildoutでは、パッケージeggをプロジェクトに追加する前にbuildout.cfgを変更します。これにより、プロジェクトに追加するパッケージを意識する必要があります。
さて、 virtualenvの問題があります。virtualenvの最も公表されている機能の1つは、明らかに--no-site-packagesオプションです。私はビルドアウトを使用しているので、そのオプションが特に役立つとは思いませんでした。Buildoutはsys.pathを管理し、含めるように指示したパッケージのみを含めます。また、システムPythonのサイトパッケージにすべてが含まれていますが、プロジェクトで使用するものがないため、競合が発生することはありません。
また、システムのパッケージングシステムを使用してインストールするパッケージもあるため、-no-site-packagesは開発プロセスを妨げるだけであることがわかりました。通常、コンパイルする必要のあるCライブラリがあるものはすべて、システムのパッケージングシステムを介してインストールします。
プロジェクトのfabfile.pyに、システムのパッケージマネージャーを介してインストールするシステムパッケージの存在をテストするためのテスト関数を含めます。
要約すると、これらのツールの使用方法は次のとおりです。
システムのパッケージマネージャー（apt-get、yam、port、fink ...） これらのいずれかを使用して、このシステムに必要なPythonバージョンをインストールします。また、cライブラリを含むlxmlのようなパッケージをインストールするためにも使用します。
easy_install 私はすべてのプロジェクトで使用するpypiからパッケージをインストールするために使用しますが、プロジェクトはこれらのパッケージに依存していません。
プロジェクトの依存関係を管理するために使用するビルドアウト。
私の経験では、このワークフローは非常に柔軟で、移植性があり、操作が簡単です。
プレーの状態を思い出す必要があるときはいつでも、私はこれらを出発点と見なします。
強みを見つけるのを簡単にお手伝いすることはできませんが、使用するプラットフォームにも依存するため、少し難しくすることができます.
たとえば、Gentoo (GNU/Liunx) ベースのコンピューターに Python パッケージをインストールする必要がある場合、g-pypiを使用して、distutils (むしろ setup.py) を使用するすべてのパッケージの ebuild を簡単に作成できます。そうすれば、それらはシステムに完全に統合され、他のすべてのツールと同様に追加、更新、および削除できます。しかし、当然、Gentoo ベースのシステムでしか機能しません。
また、 yolkを使用して、システム (Gentoo だけでなく) に easy_install を介してインストールされたすべてのパッケージを調べることができます。
私がコードを書くときは、distutils (Portage ebuild を非常に簡単にビルドできるため) と、基本的な setuptools 機能を使用するか、プログラムを整理して、プログラム フォルダーからダウンロードして実行できるようにします (理想的には、ソース アーカイブ/クローンを解凍するだけです)。リポジトリはどこかにあります）。これは完璧な解決策ではありませんが、コアの python チームがどちらに移動したいかを決定するまで、消える可能性のあるパスに (もう) 修正したくありません。