あなたと Python 今すぐパッケージン PyCon JP 2018 aodag

グ

お前誰よ ▶ aodag ▶ opencollector ▶ pyramid ▶ pip, distlib

Agenda ▶ PyPA ツールアップデート ▶ pip ▶ setuptools ▶ pypi.org ▶ pipenv ▶ mypy 対応 ▶ PEP517, 518 ▶ その他 PEP アップデート

PyPA ▶ Python Packaging Authority ▶ PEP の提案 ▶ ツールのメンテナンス ▶ pypi のメンテナンス

tools ▶ pip: インストーラー ▶ setuptools: パッケージャー ▶ wheel: wheel フォーマットパッケージャー ▶ twine: アップローダー ▶ virtualenv: 仮想環境 ▶ pipenv: pip+virtualenv+pifile を包括的に取り扱うツール ▶ pipfile: 依存ライブラリのフォーマット ▶ warehouse: pypi ▶ manylinux: docker イメージ ▶ pep517: PEP517 build API の実装 ▶ etc

tool chain Figure 1: ecosystem

今日の setuptools

今日の pip ▶ 18 ▶ 去年は 9.0.1

pip18 Figure 2: pip-history

calver ▶ 2018 年なので 18 ▶ pipenv 2018.7.1 ▶ 揃えてほしい

今日の setuptools ▶ 40.2.0 ▶ 去年は 36.4.0

setuptools の名前空間パッケージ対応 ▶ 同じパッケージ以下のモジュールを複数の配布物にする仕 組み ▶ zope,repoze,plone などが大活用している ▶ legacy namespace packages ▶ pkg_resources.declare_namespace で導入された ▶ pathlib.extend_path で一部標準ライブラリ化 ▶ native namespace packages ▶ PEP 420 – Implicit Namespace Packages で名前空間パッケー ジが標準化された ▶ python3.3 から利用可能

legacy namespace package try: __import__('pkg_resources').declare_namespace(__name__) except ImportError: __path__ = __import__('pkgutil').extend_path(__path__,

legacy namespace packages と native namespace packages ▶ legacy では __init__.py でコントロールしていた ▶ native では __init__.py が存在しないディレクトリが名前 空間パッケージ

setuptools の対応 ▶ find_packages は __init__.py が存在するディレクトリを 辿っている ▶ __init__.py がなくなった native namespace packages を find_packages は辿れない ▶ find_namespace_pacages が 40.1.0 で導入された

pypi.org リニューアル Figure 3: pypi ▶ warehouse ▶ メンテナーページ

pip/virtualenv の課題 ▶ pip が virtualenv の中で動く ▶ たくさん pip がある ▶ pip install したのに import できない！ とか言われがち ▶ virtualenv を作るというのが特有 ▶ PATH の切り替えが必要 ▶ pip freeze での管理はナイーブ ▶ 特殊なノウハウ、テクニック

pipfile ▶ dependencies と dev_dependencies ▶ 直接依存とは別に間接依存のライブラリも管理 ▶ バージョンロックファイル

pipenv ▶ virtualenv を外から管理する ▶ pipenv コマンドは 1 つだけ ▶ 遅い

pipenv を使う $ pipenv --python=3.7 $ pipenv install requests $ pipenv install pytest --dev $ pipenv run pytest $ pipenv update

pipenv をパッケージ開発に使う ▶ setup.py があれば editable インストール可能 ▶ pipenv install -e . ▶ setup.py や setup.cfg に直接依存関係などを記述 ▶ テストツールなどは pipfile の dev_dependencies で扱える ▶ pipenv install --dev pytest flake8 black … ▶ もう tests_require や extras_require[testing] いらな いんじゃないか？ ▶ pipenv install --dev -e.[testing] といった方法も 可能

黎明期 $ python ez_setup.py $ easy_install pip $ pip install virtualenv $ virtualenv venv $ . venv/bin/activate (venv) $ pip --version ▶ oh, many installers

pypa 発足から wheel 標準化 $ python get-pip.py $ pip install virtualenv $ virtualenv venv $ . venv/bin/activate (venv) $ pip --version ▶ many pips!

標準化 ensurepip + venv $ python -m venv venv $ . venv/bin/activate (venv) $ pip --version ▶ battery included

pipenv $ pip install pipenv $ pipenv --python=3.7 ▶ what’s pip?

PEP517,PEP518 ▶ setuptools 以外で wheel を作成する方法 ▶ pip が sdist をインストールするときの挙動を明確にする ▶ pyproject.toml ▶ いつから PyPI にあげられるのか？ ▶ pip の PEP517 対応に関する issue ▶ https://github.com/pypa/pip/issues/5407

PEP517 A build-system independent format for source trees ▶ ビルドツールは build API を提供するようにしましょう ▶ build API の指定は pyproject.toml の build-system で指定す るようになります ▶ build-system.required でビルドツールを指定 ▶ build-system.build-backend で API のエントリポイント を指定 ▶ API エントリポイントは build_wheel 関数を提供していな ければならない ▶ pip などのインストーラはこれらの API を呼び出して作成さ れた wheel をインストールする ▶ pyproject.toml がなければ従来の setup.py によるビルド方法 にフォールバックする

PEP518 Specifying Minimum Build System Requirements for Python Projects ▶ pyproject.toml を配布物のトップレベルに配置する ▶ toml 形式 ▶ PEP517 による build-system セクションは必須 ▶ tool セクション以下はそれぞれのビルドシステムが自由に使 える

PEP517, PEP518 に対応しているツール ▶ flit ▶ PyPA で作ってるわけではない ▶ PEP517 author(tkluyver) が開発している ▶ 慣例に従った簡単なメタデータ ▶ トップレベルパッケージ ▶ パッケージ名 = 配布物名 ▶ __version__ = version ▶ __doc__ = description ▶ pyproject.toml ▶ 依存関係 ▶ エントリポイント

flit の pyproject.toml [build-system] requires = ["flit"] build-backend = "flit.buildapi" [tool.flit.metadata] module = "flit" author = "Thomas Kluyver" author-email = "[email protected]" requires = [ "requests (>=2.6)", "configparser; python_version == '2.7'", ]

flit によるパッケージング $ flit build $ flit publish ▶ pip がまだ PEP517 に対応していない ▶ flit コマンドで wheel を作成して pypi にアップロード ▶ どんなビルドツールでも wheel にして pypi にあげてしまえば なんの問題もない ▶ pyproject.toml は sdist のビルドプロセスを明確にするもの ▶ good bye setuptools!

pyproject.toml vs Pipfile ▶ Pipfile は基本的にはパッケージ使う側の話 ▶ Pipfile はパッケージメタデータを持たないので、これだけで 配布物のパッケージングはできない ▶ Pipfile は setuptools の editable を扱えるのでパッケージ開発 でも活用できる ▶ pyproject.toml はパッケージを作る側の話 ▶ 例えば flit は editable 相当の機能を持っている

setuptools を捨てるべきか？ ▶ なくてもいいように整備が進んでいる気がする ▶ 捨てるべきというほどではない ▶ もっといいツールができたら移行しやすくなってればいいな

mypy 対応 ▶ PEP 561 – Distributing and Packaging Type Information ▶ mypy の typing スタブを配る方法 ▶ type hint を含む配布物と明示する方法

PEP 561 Distributing and Packaging Type Information ▶ トップレベルパッケージ以下に py.typed という名前のファ イルをマーカーとして同梱する ▶ stub only packages ▶ foo のための typing スタブを foo-stubs という名前空間と して扱う ▶ numpy のサンプル numpy-stubs ▶ trove classifer についてはまだ言及なし

その他パッケージング関連 PEP アップデート ▶ PEP 426 – Metadata for Python Software Packages 2.0 ▶ withdrawn! ▶ 派生したそれぞれの PEP で進められるはず ▶ PEP 491 – The Wheel Binary Package Format 1.9 ▶ wheel フォーマットにデータディレクトリを含めるための話 ▶ draft なのでまだツールの wheel では未サポート ▶ PEP 566 – Metadata for Python Software Packages 2.1 ▶ 最初は Metadata 1.6 として提案されてたが 2.0 廃案により 2.1 になった ▶ long_description_content_type 追加 ▶ PyPI で Markdown を使えるようになった

まとめ ▶ pipenv ▶ 説明する側としては歓迎すべき機能性です ▶ Pipfile と pyproject.toml ってファイルが増えるよ！ ▶ パッケージを使う側と作る側で変わるので両方同時に使うこ とにはならないはず？ ▶ Metadata 2.0 は巨大すぎましたね。 ▶ 派生でそれぞれ議論