配布、distutils、setuptools、distutils2の違いは？

状況

私はオープンソースライブラリをPython 3に移植しようとしています（誰かが疑問に思っている場合はSymPy）。

その2to3ため、Python 3のビルド時に自動的に実行する必要があります。そのためには、を使用する必要がありますdistribute。そのため、現在のシステムを移植する必要があります（doctestによると）distutils。

問題

残念ながら、私はこれらのmodules-違いだかわからないんだけどdistutils、distribute、setuptools。すべてが互いにフォークされているように見え、ほとんどの状況（ただし、実際にはすべてではない）で互換性があるように意図されているため、ドキュメントなどは最も簡単です。

質問

誰かが違いを説明できますか？何を使うべきですか？最新のソリューションは何ですか？（余談ですが、への移植に関するガイドもありがたく思いDistributeますが、それは質問の範囲を少し超えています...）

2020年3月の時点で、この質問に対する他のほとんどの回答は数年古くなっています。Pythonパッケージの問題に関するアドバイスに出くわしたときは、公開日を確認することを忘れないでください。古い情報は信用しないでください。

ユーザーガイドを包装Pythonは読む価値があります。すべてのページに「最終更新日」が表示されるので、マニュアルの新しさを確認でき、非常に包括的です。それがPython Software Foundationのpython.orgのサブドメインでホストされているという事実は、それに信憑性を追加するだけです。ここでは、プロジェクトの概要ページが特に関連しています。

ツールの概要：

Pythonのパッケージングランドスケープの概要は次のとおりです。

サポートされているツール：

• distutilsPythonでパッケージ化するための標準ツールです。標準ライブラリ（Python 2およびPython 3）に含まれています。シンプルなPythonディストリビューションには便利ですが、機能が不足しています。スクリプトにdistutilsインポートできるPythonパッケージを紹介しますsetup.py。

  • _{公式ドキュメント | distutilsPythonパッケージユーザーガイドのセクション}

• setuptoolsDistutilsの制限を克服するために開発され、標準ライブラリには含まれていません。と呼ばれるコマンドラインユーティリティが導入されましたeasy_install。またsetuptools、setup.pyスクリプトにpkg_resourcesインポートできるPythonパッケージと、ディストリビューションと共にインストールされたデータファイルを見つけるためにコードにインポートできるPythonパッケージも導入しました。その落とし穴の1つは、distutilsPythonパッケージをサルパッチすることです。でうまく動作するはずpipです。それは定期的なリリースを見ています。

  • _{公式ドキュメント | Pypiページ | GitHubリポジトリ | setuptoolsPythonパッケージユーザーガイドのセクション}

• scikit-buildコンパイルされたPython拡張機能をビルドするためにCMakeを内部で使用する改良されたビルドシステムジェネレーターです。scikit-buildはdistutilsに基づいていないため、実際には制限はありません。ninja-buildが存在する場合、scikit-buildは大規模なプロジェクトを他の3倍以上の速度でコンパイルできます。でうまく動作するはずpipです。

  • _{公式ドキュメント | Pypiページ | GitHubリポジトリ | scikit-buildPythonパッケージユーザーガイドのセクション}

• distlibは、などの上位レベルのツールで使用される機能を提供するライブラリですpip。

  • _{公式ドキュメント | Pypiページ | Bitbucketレポ | distlibPythonパッケージユーザーガイドのセクション}

• packagingpipやのようなより高レベルのツールで使用される機能を提供するライブラリでもありますsetuptools

  • _{公式ドキュメント | Pypiページ | GitHubリポジトリ | packagingPythonパッケージユーザーガイドのセクション}

非推奨/廃止されたツール：

• distributeのフォークでしたsetuptools。同じ名前空間を共有しているため、Distributeがインストールされている場合は、Distributeで配布されimport setuptoolsたパッケージを実際にインポートします。DistributeはSetuptools 0.7にマージされたため、Distributeを使用する必要はありません。実際、PypiのバージョンはSetuptoolsをインストールする互換性レイヤーにすぎません。

• distutils2を最大限に活用する試みdistutilsでsetuptoolsありdistribute、Pythonの標準ライブラリに含まれる標準ツールになりました。アイデアはdistutils2古いPythonバージョンに配布distutils2されpackaging、Python 3.3に名前が変更され、標準ライブラリに含まれるようになるというものでした。これらの計画は意図したとおりに進んでいませんでしたが、現在、distutils2放棄されたプロジェクトです。最新のリリースは2012年3月で、そのPypiホームページはその死を反映するように最終的に更新されました。

その他：

他のツールもあります。興味がある場合は、Python Packaging User GuideのProject Summariesをご覧ください。私は、そのページを繰り返さないために、としただけについての質問、マッチング答えを保つために、それらをすべて表示されませんdistribute、distutils、setuptoolsとしますdistutils2。

勧告：

このすべては、あなたに新しいものであり、あなたが開始する場所がわからない場合、私は学習をお勧めしますsetuptoolsとともに、pipおよびvirtualenv、そのすべての作業は非常によく一緒に。

あなたに探しているならvirtualenv、あなたはこの問題に興味があるかもしれない：違いは何ですかvenv、pyvenv、pyenv、virtualenv、virtualenvwrapper、など？。（はい、知っています、私はあなたとうめきます。）

私はdistutilsのメンテナーであり、distutils2 / packagingの貢献者です。私はConFoo 2011でPythonパッケージングについて話しましたが、最近では、その拡張バージョンを作成しています。それはまだ公開されていないので、ここに物事を定義するのに役立つはずの抜粋があります。

• Distutilsは、パッケージ化に使用される標準ツールです。単純なニーズにはかなりうまく機能しますが、制限があり、拡張するのは簡単ではありません。

• Setuptoolsは、不足しているdistutils機能を満たし、新しい方向性を模索したいという願望から生まれたプロジェクトです。一部のサブコミュニティでは、これは事実上の標準です。これは、Pythonコア開発者が嫌うサルパッチングと魔法を使用しています。

• Distributeは、開発ペースが遅すぎ、進化させることが不可能であると開発者が考え始めたSetuptoolsのフォークです。distutils2が同じグループによって開始されたとき、その開発はかなり遅くなりました。2013年8月の更新：配布がsetuptoolsにマージされて廃止されました。

• Distutils2は、distutilsコードベースのフォークとして開始された新しいdistutilsライブラリで、セットアップツール（一部はPEPで徹底的に議論されたもの）から得られた優れたアイデアと、pipに触発された基本的なインストーラーです。 Distutils2のインポートに使用する実際の名前はpackaging、Python 3.3以降の標準ライブラリ、またはdistutils22.4以降および3.1〜3.2にあります。（バックポートは間もなく利用可能になります。） Distutils2はPython 3.3リリースを作成せず、保留にされました。

より詳しい情報：

• Distutilsの運命– Pyconサミット+パッケージングスプリントの詳細レポート
• DistutilsとDistutils2の簡単な違い

すぐにガイドを完成させたいと思います。各ライブラリの長所と短所、および移行ガイドに関する詳細が含まれます。

注：回答は非推奨になり、Distributeは廃止されました。Python Packaging Authorityが設立され、これを整理するために多くの作業を行ったため、この回答は無効になりました。

はい、わかりました。：-o現在のところ、優先パッケージはDistributeであると思います。これは、distutils（元のパッケージシステム）の拡張であるsetuptoolsのフォークです。Setuptoolsはメンテナンスされていなかったため、フォークされて名前が変更されましたが、インストールされると、setuptoolsのパッケージ名が使用されます。今ではほとんどのPython開発者がDistributeを使用していると思いますが、確かにそうです。

私はあなたの元の問題の疑いのない仮定に対処することなくあなたの二次的な質問に答えたと思います：

私はオープンソースライブラリ（SymPy、だれか不思議に思っています）をPython 3に移植しようとしています。これを行うには、Python 3用にビルドするときに2to3を自動的に実行する必要があります。

あなたはあり、ない必要。他の戦略はhttp://docs.python.org/dev/howto/pyportingで説明されています

そのためには、distributeを使用する必要があります。

あなたは可能：のを配布するさまざまな方法で、コードのビルド時の2to3は変換（ないドキュメンテーション文字列）のdistutilsがサポートする:) http://docs.python.org/dev/howto/pyporting#during-installation

幸運なことに、Pythonのパッケージングの混乱がContinuumの「conda」パッケージマネージャーによって大幅にクリーンアップされた2014年後半にこの質問を更新しました。

特に、condaはすぐにcondaの「環境」の作成を可能にします。さまざまなバージョンのPythonを使用して環境を構成できます。例えば：

conda create -n py34 python=3.4 anaconda

conda create -n py26 python=2.6 anaconda

Pythonのバージョンが異なる2つの（「py34」または「py26」）Python環境を作成します。

その後、Pythonの特定のバージョンで環境を呼び出すことができます。

source activate <env name>

この機能は、異なるバージョンのPythonを処理する必要がある場合に特に役立ちます。

さらに、condaには次の機能があります。

• Pythonに依存しない
• クロスプラットフォーム
• 管理者権限は不要
• スマートな依存関係管理（SATソルバーによる）
• リンクしなければならない可能性のあるC、Fortran、およびシステムレベルのライブラリをうまく扱います。

この最後の点は、科学計算分野にいる場合は特に重要です。