setup.py は非推奨になりましたか？¶
いいえ、 setup.py および Setuptools は非推奨にはなっていません。
Setuptools は、 ビルドバックエンド として Python のプロジェクトをパッケージングすることに完璧に使用可能です。そして、 setup.py は、例えば TOML の代わりにたまたま Python で書かれている Setuptools 向けの正当な設定ファイルです (nox とその設定ファイルである nox.filepy や pytest と conftest.py のような他のツール類でも、よく似たパターンが使われています)。
しかしながら、 python setup.py および setup.py をコマンドラインツールとして使うことは非推奨になりました。
その意味するところは、次のようなコマンドを実行することはもはや 許されない ということです:
python setup.py installpython setup.py developpython setup.py sdistpython setup.py bdist_wheel
代わりにどのようなコマンドを使うべきでしょうか？¶
非推奨 |
推奨事項 |
|---|---|
|
|
|
|
|
|
|
setuptools ベースのプロジェクトをインストールするためには、python setup.py install のように setup.py の install コマンドを使うことが普通でした。今日では、python -m pip install . のように pip を直接に使う方法が推奨されています。ここでドット . は、実際にはファイルシステム上のパスなので、これはカレントディレクトリを示すパス表現です。なんと、 pip は install サブコマンドへの引数の形で、ローカルのファイルシステム上のパスをプロジェクトのソースコードツリーを置くべき場所として受け付けるのです。そういうことですから、これもまた正当なコマンドということになります: python -m pip install path/to/project。
編集可能 <editable> モードとしても知られる 開発 <develop> モードでのインストールのためには、 python setup.py develop の代わりに pip の install サブコマンドの --editable オプションを使うことができます: python -m pip install --editable .。
ソースコード配布物 および wheels をビルドする方法で推奨されていて単純かつ直截なひとつのやり方は、 ビルド ツールを python -m build のようなコマンドから使って両方の配布物フォーマットの生成を開始することです。いずれか片方の配布物だけを生成するのであれば、必要に応じて --sdist や --wheel のオプションを使うことができます。build ツールは個別にインストールする必要があることに注意してください。
コマンド python setup.py install は、setuptools のバージョン 58.3.0 で非推奨になりました。
他のコマンドについてはどうでしょうか？¶
他の python setup.py コマンドを置き換えるものは何でしょうか？
python setup.py test¶
推奨されるものは、pytest のようなテストランナーを使うことです。
python setup.py check, python setup.py register, および python setup.py upload¶
信頼されている代替物は twine です:
python -m twine check --strict dist/*python -m twine register dist/*.whl[2]python -m twine upload dist/*
python setup.py --version¶
実行可能な代替案は (他にもありますが) setuptools-scm に頼ることでしょう:
python -m setuptools_scm
残りのコマンド群¶
このガイド文書では、それらコマンド群の代替案について示唆しません:
|
|
|
|
カスタムコマンドについてはどうでしょうか？¶
同様に、カスタムコマンドの setup.py も非推奨になっています。そのようなカスタムコマンドについては、タスクランナーツールか他の類似ツールに移植することをお勧めします。そのようなツールの例を挙げれば: chuy、 make、 nox もしくは tox、 pydoit、 pyinvoke、 taskipy、 そして thx。
カスタムビルドステップについてはどうでしょうか？¶
例えば、 build_py 、 build_ext や bdist_wheel のように既存のステップを上書きしたり新しいビルドステップを追加したりするカスタムビルドステップは、非推奨にはなっていません。そのようなステップは期待通りに自動的に呼び出されるでしょう。
setup.py は削除されるべきですか？¶
setup.py を実行可能なスクリプトとして使うことは非推奨になりましたが、しかし、setuptools に対する設定ファイルとして使うことは完全に正当です。setup.py を修正する必要はないでしょう。
pyproject.toml は必須ですか？¶
技術的には無くてはならないというわけではありませんが、プロジェクトがそのソースコードツリーのルート部分に pyproject.toml ファイルを持つことは 強く推奨 されています:
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
これについては、説明文書の setup.py 近代化プロジェクト にもっと詳しい説明があります。
pyproject.toml ファイルとその [build-system] テーブルが存在しない場合、 ビルドフロントエンド にとって標準的なフォールバックの振る舞いは、 ビルドバックエンド が setuptools であると仮定することです。
どうして？一体全体どういうこと？¶
ひとつの見方は、setuptools のスコープが、いまや、ビルドバックエンドの役割に限定されているということです。