setuptoolsはPhillip J. Ebyが2004年にdistutils拡張として発表したPythonのビルドツールで、20年以上にわたりPyPIパッケージ作成のデファクト基盤として動き続けている。PEP 517/518以降は「build backendの一つ」という位置付けに整理され、setup.py時代から大きく姿を変えた。本稿ではsetuptoolsの歴史、setup.pyとpyproject.tomlの関係、最近の重要変更、現代における役割を順に整理する。
この記事の目次
- setuptoolsの歴史と役割
- setup.pyとpyproject.toml
- 近年のリリースで重要な変更
- 現代における立ち位置
- まとめ
setuptoolsの歴史と役割
setuptoolsは2004年にdistutilsを拡張する形で登場し、entry points機構やpkg_resources、依存解決などPython packagingの初期発展を支えた。EasyInstallと組み合わせて使われた時代には、いわゆる.egg形式がパッケージ配布の主流であった。2012年のPEP 427でwheelが標準化されると、.eggは徐々に姿を消し、setuptoolsもwheelビルドを主機能とするようになった。20年以上の歴史の中で、Pythonエコシステムの土台として静かに機能し続けている。
2018年のPEP 517/518に対応して以降、setuptoolsは「Pythonビルドのデフォルトbackend」として整理された。pyproject.tomlの[build-system].build-backendに "setuptools.build_meta" を指定すれば現代的なビルドが可能となる。setup.pyを書かなくてもsetup.cfgやpyproject.tomlで設定を完結できるようになり、命令型のsetup.pyから宣言的な設定への移行が進んでいる。
setup.pyとpyproject.toml
歴史的にsetup.pyはPythonコードで書かれ、from setuptools import setup; setup(name=..., install_requires=...) のような呼び出しでビルドを定義した。命令型ゆえに任意のPythonコードが混入でき、PyPIで公開される時にも実行リスクがあった。PEP 517はこの問題を解決するため、frontend(pipなど)が独立した孤立環境でbackend(setuptoolsなど)を呼び出すモデルを規定した。
現代では[project] sectionをpyproject.tomlに書き、build-systemにsetuptoolsを指定するだけで多くのケースをカバーできる。Cython拡張やCMakeとの連携が必要な複雑なケースでは依然としてsetup.pyが必要だが、その場合も最小限のコードで済むよう設計が改善されている。setup.cfgで宣言する手段も残っており、組織のコーディング規約や移行段階に応じて柔軟に選べる。Hatchlingやflit_coreなど他のbackendも同じpyproject.toml中心モデルで動くため、ユーザの体験は大きく揃ってきた。
近年のリリースで重要な変更
setuptools 61(2022年)はPEP 621対応として[project]節を直接読めるようにし、setup.pyを書かないプロジェクト体験を実現した重要なマイルストーンだ。それまでsetuptoolsはsetup.cfgまたはsetup.pyを唯一の設定ソースとしていたが、61以降は[project]節を一次データソースとして優先する。これによりPoetryやHatchから移行してきたプロジェクトでも、setuptoolsをbackendに据えるだけでpyproject.toml中心のワークフローを継続できる。
もう一つの大きな変更がeditable installのPEP 660準拠化だ。従来のsetup.py develop は.pthファイルをsite-packagesに置く独特の仕組みで、IDE補完やnamespace packageと相性が悪い場面があった。PEP 660ベースのpip install -e . は.pthファイルではなくeditable wheelを介して導入されるため、よりクリーンに振る舞う。setuptools 66以降でこの新方式が安定し、現在は新しいbackendも同じ仕組みを共有している。
現代における立ち位置
PoetryやHatch、uvといった新世代ツールが台頭した現代でも、setuptoolsは依然として最も広く使われるbuild backendである。PyPIのトップ1000パッケージを調査すると、過半数がsetuptoolsをbackendに使い続けている。歴史的負債というよりも「最も汎用的でテストされた選択肢」として残っており、特にCython拡張、Cython自身、NumPy、SciPyといった複雑なネイティブビルドが必要なライブラリで重要だ。
setuptoolsの開発はJason R. CoombsとPyPAコアメンバが中心となって続けており、月次に近いペースでリリースが続いている。distutilsはPython 3.12で標準ライブラリから削除され、setuptoolsが提供する互換実装に置き換わった。これにより「distutilsがあるからsetuptoolsを避ける」という選択肢自体がなくなり、PythonビルドはPEP 517 backendを通して行うのが事実上の標準となった。setuptoolsを使うかhatchlingを使うかは設計判断だが、どちらを選んでもpyproject.toml中心の世界に立脚できる。
まとめ
setuptoolsは2004年の登場から20年以上、Pythonビルドの基盤として進化を続けてきた。PEP 517/518以降は他のbackendと並ぶ選択肢になったが、その歴史的厚みと拡張ビルドへの対応力は他に代えがたい。新興のhatchlingやmaturinと組み合わせて検討する際にも、setuptoolsの仕組みを理解しておくことが現代Python開発の前提となる。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント