Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
あなたとPython今すぐパッケージング
Search
Atsushi Odagiri
September 17, 2018
Programming
3.8k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
あなたとPython今すぐパッケージング
Atsushi Odagiri
September 17, 2018
More Decks by Atsushi Odagiri
See All by Atsushi Odagiri
setuptoolsの最近
aodag
1
3k
[Pycon Kyushu 2019] Pythonでの開発を効率的に進めるためのツール設定
aodag
9
46k
LL2018 LT Pythonパッケージマネージャーはどれがおすすめ?
aodag
2
1.8k
Other Decks in Programming
See All in Programming
act1-costs.pdf
sumedhbala
0
210
霧の中の代数的エフェクト
funnyycat
1
360
Claude Opus 4.6以後の受託開発エンジニアの変化(Claude Code開発ノウハウ大公開スペシャルbyクラスメソッド)
iidatakuma
1
650
【やさしく解説 設計編 #1】「ドメイン駆動」と「実装駆動」ってなに? 〜設計の考え方を、たとえ話で学ぼう〜
panda728
PRO
1
120
これからAgentCoreを触る方へトレンドはGatewayです
har1101
6
490
ローカルLLMでどこまでコードが書けるか -縮小版 / How much code can be written on a local LLM Shortened
kishida
2
190
1B+ /day規模のログを管理する技術
broadleaf
0
140
Vite+ Unified Toolchain for the Web
naokihaba
0
750
1年で人数1.5倍、PR数5.5倍増。 品質とアウトカムはどうなったか、 何が効いたか
ike002jp
0
130
使用 Meilisearch 建立新聞搜尋工具
johnroyer
0
140
技術記事、 専門家としてのプログラマ、 言語化
mizchi
14
7.4k
AI時代、エンジニアはどう育つのか -未経験エンジニアの成長を間近で見て考えたこと-
thasu0123
0
110
Featured
See All Featured
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
63
55k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
240
The browser strikes back
jonoalderson
0
1.4k
Designing for Performance
lara
611
70k
Into the Great Unknown - MozCon
thekraken
41
2.6k
Tell your own story through comics
letsgokoyo
1
990
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
72
40k
WENDY [Excerpt]
tessaabrams
11
38k
BBQ
matthewcrist
89
10k
How to build a perfect <img>
jonoalderson
1
5.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.4k
Marketing to machines
jonoalderson
1
5.6k
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 = "
[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 は巨大すぎましたね。 ▶ 派生でそれぞれ議論