Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
あなたとPython今すぐパッケージング
Atsushi Odagiri
September 17, 2018
Programming
2
2.9k
あなたとPython今すぐパッケージング
Atsushi Odagiri
September 17, 2018
Tweet
Share
More Decks by Atsushi Odagiri
See All by Atsushi Odagiri
[Pycon Kyushu 2019] Pythonでの開発を効率的に進めるためのツール設定
aodag
9
45k
LL2018 LT Pythonパッケージマネージャーはどれがおすすめ?
aodag
2
1.2k
Other Decks in Programming
See All in Programming
Rust、何もわからない...#3
estie
0
160
테라폼으로 ECR 관리하기 (How to Manage ECR with Terraform)
posquit0
0
530
Better Angular Architectures: Architectures with Standalone Components @DWX2022
manfredsteyer
PRO
1
410
Babylon.jsで作ったsceneをレイトレーシングで映えさせる
turamy
1
210
回帰分析ではlm()ではなくestimatr::lm_robust()を使おう / TokyoR100
dropout009
0
4.5k
Pythonによる開発をアップデートするライブラリの紹介
daikikatsuragawa
1
600
Amazon Lookout for Visionで 筆跡鑑定してみた
cmnakamurashogo
0
160
Isar勉強会
hoddy3190
0
470
Cloudflare WorkersでGoのHTTPサーバーを動かすライブラリを作った話
syumai
0
150
Carp言語さわってみた 〜鯉を取り戻せ編〜
tsin45
0
100
それ全部エラーメッセージに書いてあるよ!〜独学でPHPプログラミングが上達するたった一つの方法〜
77web
1
150
設計の考え方とやり方
masuda220
PRO
54
30k
Featured
See All Featured
Unsuck your backbone
ammeep
659
55k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
151
13k
In The Pink: A Labor of Love
frogandcode
131
21k
Code Reviewing Like a Champion
maltzj
506
37k
The World Runs on Bad Software
bkeepers
PRO
57
5.4k
Stop Working from a Prison Cell
hatefulcrawdad
262
17k
Atom: Resistance is Futile
akmur
255
20k
Testing 201, or: Great Expectations
jmmastey
21
5.5k
jQuery: Nuts, Bolts and Bling
dougneiner
56
6.4k
Why Our Code Smells
bkeepers
PRO
324
55k
Designing for humans not robots
tammielis
241
24k
How to name files
jennybc
40
63k
Transcript
あなたと 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 = "thomas@kluyver.me.uk" 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 は巨大すぎましたね。 ▶ 派生でそれぞれ議論