私はオープンソースのライブラリをPython 3に移植しようとしています。( SymPy 、誰かが疑問に思っているなら)
そのため、Python 3用にビルドするときは2to3
を自動的に実行する必要があります。そのためにはdistribute
を使用する必要があります。したがって、(doctestによると)現在のシステムをdistutils
に移植する必要があります。
残念ながら、これらのモジュール、distutils
、distribute
、setuptools
の違いが何であるかはわかりません。これらの文書はすべて互いに分岐しているように見え、ほとんどの状況で互換性があるように意図されている(しかし実際にはすべてではない)など、最もわかりやすくなっています。
誰かが違いを説明できますか?何を使うべきですか?最も近代的な解決策は何ですか? (余談ですが、Distribute
への移植に関するガイドもお寄せいただきありがとうございますが、それは質問の範囲を超えたちょっとした作業です…)
2017年1月現在、この質問に対する他のすべての回答は少なくとも2年間は古くなっています。 Pythonのパッケージングに関する問題についてのアドバイスに遭遇したときは、必ず出版日を確認し、古くなった情報を信頼しないでください。
Python Packaging User Guide は読む価値があります。各ページには「最終確認日」が表示されているので、マニュアルの最新性を確認することができます。これは非常に包括的です。それがPython Software Foundationのpython.orgのサブドメインでホストされているという事実はそれに信憑性を追加するだけです。 Project Summaries ページはここで特に関連があります。
これが2017年1月のPythonパッケージングの展望の要約です。
Distutilsは依然としてPythonでパッケージ化するための標準的なツールです。これは標準ライブラリ(Python 2とPython 3.0から3.6)に含まれています。単純なPythonディストリビューションには便利ですが、機能が不足しています。 setup.py
スクリプトにインポートできるdistutils
Pythonパッケージを紹介します。
SetuptoolsはDistutilsの制限を克服するために開発されたもので、標準ライブラリには含まれていません。 easy_install
というコマンドラインユーティリティが導入されました。また、setup.py
スクリプトにインポートできるsetuptools
Pythonパッケージ、および配布物と共にインストールされたデータファイルを見つけるためにコードにインポートできるpkg_resources
Pythonパッケージも紹介しました。その欠点の1つは、distutils
Pythonパッケージにモンキーパッチを適用することです。 pip
とうまく動作するはずです。 通常のリリースを見ています。
scikit-buildは、内部でCMakeを使用してコンパイル済みのPython拡張機能を構築する改良されたビルドシステムジェネレータです。 scikit-buildはdistutilsに基づいていないため、実際にはその制限はありません。 ninja-buildが存在する場合、scikit-buildは大規模プロジェクトを他の方法よりも3倍以上速くコンパイルすることができます。 pip
とうまく動作するはずです。 通常のリリースを見ています。
配布はSetuptoolsのフォークでした。同じ名前空間を共有していたので、Distributeがインストールされている場合、import setuptools
は実際にDistributeで配布されたパッケージをインポートします。 Distributeは、Setuptools 0.7にマージされたので、これ以上Distributeを使用する必要はありません。実際、Pypiのバージョンは、Setuptoolsをインストールするための単なる互換性レイヤです。
Distutils2は、Distutils、Setuptools、およびDistributeを最大限に活用し、Pythonの標準ライブラリに含まれる標準ツールになるための試みです。その考えは、Distutils2は古いPythonバージョン用に配布され、そしてDistutils2はPython 3.3ではpackaging
にリネームされ、それが標準ライブラリに含まれるようになるというものでした。しかし、これらの計画は意図したとおりには進んでおらず、現在のところ、Distutils2は放棄されたプロジェクトです。最新のリリースは2012年3月で、そのPypiホームページはついにその死を反映して更新されました。
Distlibは、以前のツールの機能のサブセットを実装することを目的としたツールですが、承認されたPEPで非常によく定義されている機能のみです。これはPyPA(Python Package Authority)のツールの1つであり、いつかPython標準ライブラリに最終的に含まれる予定です。 まだアルファソフトウェアと見なされているので、エンドユーザーは注意してください。
いくつかのより多くのツール (例:Bento)がありますが、それらはこの回答投稿にはあいまいすぎたりニッチだったり、早かったり未開発なので、私は言及しません。 。
結論として、これらすべてのオプションのうち、あなたの要件が非常に基本的でDistutilsしか必要としない限り、私はSetuptoolsをお勧めします。 Setuptoolsは、VirtualenvとPip、私が強くお勧めするツールと非常によく連携しています。 VirtualenvとPipは、どちらもPyPAの一部であるため、公式と見なすことができます。Python3では、 ensurepip
が出荷されるようになりました(一部のシステムにpip
をインストールするのに役立ちます)。
Virtualenvを検討しているなら、この質問に興味があるかもしれません: venv
、pyvenv
、pyenv
、virtualenv
、virtualenvwrapper
などの違いは何ですか? 。 (はい、私は知っています、私はあなたとうめき声を上げます)
ちなみに、Python 2と3の両方で、Setuptools/Distributeの合併を認識した最初のリリースであるため、Virtualenv 1.10以降を使用することをお勧めします。
私はdistutilsのメンテナでありdistutils 2 /パッケージングの貢献者です。私はConFoo 2011でPythonのパッケージングについて話しました。そして最近私はその拡張版を書いています。まだ公開されていないので、ここでは物事を定義するのに役立つはずの抜粋を示します。
Distutilsはパッケージに使用される標準的なツールです。これは単純なニーズに対してはかなりうまく機能しますが、制限されており、拡張するのは簡単ではありません。
Setuptoolsは、欠けているdistutilsの機能を補い、新しい方向性を探るという願望から生まれたプロジェクトです。一部のサブコミュニティでは、デファクトスタンダードです。それはPythonのコア開発者によって眉をひそめられる猿パッチと魔法を使います。
Distributeは、開発のペースが遅すぎ、それを進化させることが不可能であると感じて開発者が始めたSetuptoolsのフォークです。 distutils2が同じグループによって開始されたとき、その開発はかなり遅くなりました。 2013年8月の更新:配布はsetuptoolsにマージされ、中止されました。
Distutils2はdistutilsコードベースのフォークとして始められた新しいdistutilsライブラリで、その中のいくつかはPEPで徹底的に議論されました。 )、およびpipに触発された基本的なインストーラ。 Distutils2をインポートするために実際に使用する名前は、Python 3.3以降の標準ライブラリでは Distutils2はPython 3.3をリリースしておらず、保留されていました。packaging
、2.4以降のバージョンではdistutils2
です。 (バックポートは近日中に利用可能になるでしょう。)
より詳しい情報:
私はすぐに私のガイドを終えたいと思っています、それは各図書館の長所と短所に関するより多くの情報と移行ガイドを含むでしょう。
注:回答は廃止予定で、配布は廃止されました。
うん、あなたはそれを手に入れました。 :-o現時点でお勧めのパッケージは Distribute で、これはsetuptoolsのフォークで、distutils(オリジナルのパッケージシステム)の拡張です。 Setuptoolsはメンテナンスされていなかったのでフォークされて名前が変更されましたが、インストール時にはsetuptoolsのパッケージ名が使用されます。私はほとんどのPython開発者が現在Distributeを使っていると思います、そして私はそれをしていると確信して言うことができます。
この問題に関する明確なコミュニティガイダンスの欠如について、多くの人々がここに不満を述べました。
現在のところ、これはツールの推奨事項に関する最も信頼できる情報源です。 https://packaging.python.org/en/latest/current.html#tool-recommendations
幸いなことにPythonのパッケージングの混乱がContinuumの " conda "パッケージマネージャによって大いに片付けられた2014年後半にこの質問を更新しました。
特に、condaはconda " environment "の作成をすぐに可能にします。あなたはあなたの環境を異なるバージョンの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には以下の機能があります。
あなたが科学コンピューティングの分野にいる場合、この最後の点は特に重要です。
私はあなたの元々の問題の中で疑問の余地のない仮定に対処することなくあなたの二次質問に答えたことを私は理解します:
私はオープンソースのライブラリ(誰か疑問に思う人はSymPy)をPython 3に移植しようとしています。これを行うには、Python 3用にビルドするときに2to3を自動的に実行する必要があります。
あなたは必要ありません、必要はありません。他の戦略は http://docs.python.org/dev/howto/pyporting で説明されています。
そのためには、distributeを使用する必要があります。
あなたmay:) distutilsは、配布時とは異なる方法で、(docstringsではなく)コードのビルド時2to3変換をサポートします。 http:/ /docs.python.org/dev/howto/pyporting#during-installation
この話題はまだ流動的です。 2013年10月31日現在、 "Python Packaging User Guide" Quick Recommendations は "現在推奨されているツールセット"を定義しています。それは今、 "The Future of Python Packaging"にリンクしていたもので、現在は1920年1月20日、5年以上後にデッドリンクになっています。 :)