Successfully reported this slideshow.
Your SlideShare is downloading. ×

パッケージングの呼び声 Python Charity Talks in Japan 2021.02

More Related Content

パッケージングの呼び声 Python Charity Talks in Japan 2021.02

  1. 1. パッケージングの呼び声 Python Charity Talks in Japan 2021.02 Atsushi Odagiri 2021-02-20
  2. 2. Outline Preface PEP 動向 さよなら distutils packaging FAQ おわりに 1
  3. 3. Preface
  4. 4. お前誰よ • aodag • パッケージングの話 • opencollector 2
  5. 5. 今日の setuptools • Feb 2, 2021 53.0.0 3
  6. 6. お詫び • パッケージの呼び声というタイトルにしましたが、資 料作成しているうちにクトゥルフ要素 (名状しがたき setup.py など) がなくなってしまったのでタイトルは気 にしないでください。 PIP…PIP…WHEEL…TWINE… WAREHOUSE…PyPI…SDIST… PIP…PIP… 4
  7. 7. PEP動向
  8. 8. PEP 561 – Distributing and Packaging Type Informa- tion • typeshed で管理されていた stub-only packages が pypi で配布されるようになりました。 • 多くのパッケージ名は types-** という名前になって います • types-numpy だけは事前に配布されていたっぽい 5
  9. 9. PEP 621 – Storing project metadata in pyproject.toml • poetry や flit などのパッケージングツールは pyproject.toml にパッケージメタデータを書く • それぞれのツール以下のセクション (tool.poetry など) にそれぞれのツールが決めたスキーマでメタデー タを書いている • 統一してきましょう 6
  10. 10. PEP 627 – Recording installed projects • PEP 376 – Database of Installed Python Distributions の更新 • RECORD と INSTALLER ファイルを明確にする • REQUESTED ファイルは廃止 7
  11. 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. 12. PEP 643 – Metadata for Package Source Distributions • sdist の時点では決まらないメタデータの値がある • sdist 時点で提供するメタデータに含めないフィールド を Dynamic フィールドってことで明確にします 9
  13. 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. 14. さよならdistutils
  15. 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. 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. 17. setup.py はもう不要? • setuptools も PEP517 対応 • setup.py がなくても pyproject.toml と setup.cfg があれば wheel 作成可能 • ただし editable install(pip install -e .) は setup.py が ないとだめ 13
  18. 18. setuptools の対応 • pypa リポジトリで distutils のソースを管理 • https://github.com/pypa/distutils • setuptools/_distutils に distutils のソースを同梱 (v48.0.0) 14
  19. 19. 我々はなにをすべきか • 直接 distutils を使うことはほぼないはず • distutils.util なんて使ってないですよね? • 特に strtobool • そのうち distutils が消えると予想して asbool というも のを作っておきました • https://pypi.org/project/asbool/ 15
  20. 20. packaging FAQ
  21. 21. PEP517 とは? • wheel を作成するための手順の定義 • これまでは setup.py を呼ぶという慣習で sdist か ら wheel を作成していた • pyproject.toml にビルドツールの設定を書く • PEP518 が pyproject.toml の定義 16
  22. 22. PEP517 対応パッケージのビルド方法は? • https://pypi.org/project/build/ • pep517.build から build へ • python -m pep517.buid • python -m build • その他ツール独自にコマンドが用意されている • poetry build • flit build 17
  23. 23. パッケージによって PyPI に wheel があったりなかった りするのは? • そのプロジェクトが作って PyPI にあげてくれないと wheel がありません • pypi で wheel を生成すべきかという議論はあります 18
  24. 24. Apple シリコンの Mac ではどういう wheel が使える? • universal2 になるはず 19
  25. 25. poetry 使うべき? • 良いと思います • git の tag からパッケージバージョンを生成するような 拡張も出てきています • poetry-dynamic-versioning • ケンオール でも使ってます :) 20
  26. 26. poetry で C 拡張を作るには? • build.py を作る方法がワークアラウンドとしてよく 知られています • distutils を import してるので、動かなくなりますね 21
  27. 27. パッケージバージョンをプログラム内部で参照できるよ うにするには? • いくつかワークアラウンドがありますが、どれもそれな りなのでこれじゃないとだめというものでもないです。 • setuptools_scm や poetry-dynamic-versioning はバージョン情報 を含んだモジュールを生成する機能があります。 • pkg_resources を使ってメタデータを取得する方法 もあります。 try: __version__ = __import__('pkg_resources') .get_distribution('foo').version except Exception: __version__ = "dev" 22
  28. 28. Linux なのに manylinux2014 の wheel をインストール してくれません • pip を新しくしないと manylinux の新しいバージョン に対応していないです • PEP599 manylinux2014(centos7 相当) pip19.3 • PEP571 manylinux2010(centos6 相当) pip19.0 • PEP513 manylinux1(centos5 相当) pip8.1.0 23
  29. 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. 30. おわりに
  31. 31. まとめ • どちらかというとツール作成者向けの結構細かい PEP が進んでいる印象 • メタデータのフィールドやファイルに関する取り決め が明確となり、ツール相互運用がしやすくなっていく はず • distutils に限らず old battery の削除 PEP があります 25
  32. 32. 参考文献 • Python Packaging User Guide • PyPA Repository • Discussions on python.org Packaging Category • Python PEPs 26

×