Python Charity Talks in Japan 2021.02

1. パッケージングの呼び声
Python Charity Talks in Japan 2021.02
Atsushi Odagiri
2021-02-20

2. Outline
Preface
PEP 動向
さよなら distutils
packaging FAQ
おわりに
1

3. Preface

4. お前誰よ
• aodag
• パッケージングの話
• opencollector
2

5. 今日の setuptools
• Feb 2, 2021 53.0.0
3

6. お詫び
• パッケージの呼び声というタイトルにしましたが、資
料作成しているうちにクトゥルフ要素 (名状しがたき
setup.py など) がなくなってしまったのでタイトルは気
にしないでください。
PIP…PIP…WHEEL…TWINE…
WAREHOUSE…PyPI…SDIST…
PIP…PIP…
4

7. PEP動向

8. PEP 561 – Distributing and Packaging Type Informa-
tion
• typeshed で管理されていた stub-only packages が
pypi で配布されるようになりました。
• 多くのパッケージ名は types-** という名前になって
います
• types-numpy だけは事前に配布されていたっぽい
5

9. PEP 621 – Storing project metadata in pyproject.toml
• poetry や flit などのパッケージングツールは
pyproject.toml にパッケージメタデータを書く
• それぞれのツール以下のセクション (tool.poetry
など) にそれぞれのツールが決めたスキーマでメタデー
タを書いている
• 統一してきましょう
6

10. PEP 627 – Recording installed projects
• PEP 376 – Database of Installed Python Distributions
の更新
• RECORD と INSTALLER ファイルを明確にする
• REQUESTED ファイルは廃止
7

11. PEP 639 – Metadata for Python Software Packages 2.2
• License フィールドに使える値を明確にする
• spdx license identifier
• Software Package Data Exchange
• spdx のライセンス ID 一覧
https://spdx.org/licenses/
• License-File フィールド追加
8

12. PEP 643 – Metadata for Package Source Distributions
• sdist の時点では決まらないメタデータの値がある
• sdist 時点で提供するメタデータに含めないフィールド
を Dynamic フィールドってことで明確にします
9

13. PEP 632 – Deprecate distutils module
• distutils は標準ライブラリから削除されます
• 3.10 で deprecation warning となりました
• po-41282: Add deprecation warning and docs for
distutils (PEP 632)
• 今後 3.12 で削除される予定
10

14. さよならdistutils

15. distutils ってなに
In Python 2.0, the distutils API was first added to
the standard library. This provided Linux distro
maintainers with a standard way of converting
Python projects into Linux distro packages, and
system administrators with a standard way of in-
stalling them directly onto target systems.
• Python パッケージを各種 OS のパッケージに変換した
り、直接インストールするための方法として用意さ
れた。
11

16. setuptools との関わり
• すでに多くの人が distutils を直接使わず、setuptools
経由で利用している
• 実質 setuptools.setup =
distutils.core.setup
• setup_requires を処理するためのフックがある
だけ
def setup(**attrs):
# Make sure we have any requirements needed
_install_setup_requires(attrs)
return distutils.core.setup(**attrs)
12

17. setup.py はもう不要?
• setuptools も PEP517 対応
• setup.py がなくても pyproject.toml と
setup.cfg があれば wheel 作成可能
• ただし editable install(pip install -e .) は setup.py が
ないとだめ
13

18. setuptools の対応
• pypa リポジトリで distutils のソースを管理
• https://github.com/pypa/distutils
• setuptools/_distutils に distutils のソースを同梱
(v48.0.0)
14

19. 我々はなにをすべきか
• 直接 distutils を使うことはほぼないはず
• distutils.util なんて使ってないですよね？
• 特に strtobool
• そのうち distutils が消えると予想して asbool というも
のを作っておきました
• https://pypi.org/project/asbool/
15

20. packaging FAQ

21. PEP517 とは？
• wheel を作成するための手順の定義
• これまでは setup.py を呼ぶという慣習で sdist か
ら wheel を作成していた
• pyproject.toml にビルドツールの設定を書く
• PEP518 が pyproject.toml の定義
16

22. PEP517 対応パッケージのビルド方法は？
• https://pypi.org/project/build/
• pep517.build から build へ
• python -m pep517.buid
• python -m build
• その他ツール独自にコマンドが用意されている
• poetry build
• flit build
17

23. パッケージによって PyPI に wheel があったりなかった
りするのは？
• そのプロジェクトが作って PyPI にあげてくれないと
wheel がありません
• pypi で wheel を生成すべきかという議論はあります
18

24. Apple シリコンの Mac ではどういう wheel が使える？
• universal2 になるはず
19

25. poetry 使うべき?
• 良いと思います
• git の tag からパッケージバージョンを生成するような
拡張も出てきています
• poetry-dynamic-versioning
• ケンオール でも使ってます :)
20

26. poetry で C 拡張を作るには？
• build.py を作る方法がワークアラウンドとしてよく
知られています
• distutils を import してるので、動かなくなりますね
21

27. パッケージバージョンをプログラム内部で参照できるよ
うにするには？
• いくつかワークアラウンドがありますが、どれもそれな
りなのでこれじゃないとだめというものでもないです。
• setuptools_scm や
poetry-dynamic-versioning はバージョン情報
を含んだモジュールを生成する機能があります。
• pkg_resources を使ってメタデータを取得する方法
もあります。
try:
__version__ = __import__('pkg_resources')
.get_distribution('foo').version
except Exception:
__version__ = "dev"
22

28. Linux なのに manylinux2014 の wheel をインストール
してくれません
• pip を新しくしないと manylinux の新しいバージョン
に対応していないです
• PEP599 manylinux2014(centos7 相当) pip19.3
• PEP571 manylinux2010(centos6 相当) pip19.0
• PEP513 manylinux1(centos5 相当) pip8.1.0
23

29. wheelのファイル名でcp39-cp39のように2回もpython
バージョンが書かれているのはなぜですか
• python API の abi を表しています
• PEP 3149 – ABI version tagged .so files
• cp39m や cp27mu, abi3 が使われることがあります
• abi3(PEP 384 – Defining a Stable ABI) は python API の
うち stable な API を使っているため ABI 互換性があり
ます
• abi3 tag のついた wheel は cPython バージョンに依存
しません
• u はユニコードの内部表現が UCS2 か UCS4 かを表しま
す。3.3 以降は UCS4 となり ABI に u 表現は必要なくな
りました。(PEP 393 – Flexible String Representation)
• m は pymalloc をメモリアロケーションに使っていると
いう意味。python3.6 以降でメモリアロケーションの実 24

30. おわりに

31. まとめ
• どちらかというとツール作成者向けの結構細かい PEP
が進んでいる印象
• メタデータのフィールドやファイルに関する取り決め
が明確となり、ツール相互運用がしやすくなっていく
はず
• distutils に限らず old battery の削除 PEP があります
25

32. 参考文献
• Python Packaging User Guide
• PyPA Repository
• Discussions on python.org Packaging Category
• Python PEPs
26