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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
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
そのテスト、説明できますか?~LWテスト戦略FW~のご紹介
nakahara
0
150
肥大化するレガシーコードに立ち向かうためのインターフェース分離と依存の逆転 / JJUG CCC 2026 Spring
hirokunimaeta
0
580
TSKaigi Night Talks 2026_TypeScriptでサプライチェーンの整合性を型に閉じ込める
geekplus_tech
0
400
C# and C++ Interoperability - cho-dotnetnew
harukasao
0
290
生成AI時代にこそ効くGo | Why Go Works in the Age of Generative AI
mom0tomo
8
3.3k
エンジニアと一緒にテストコードの設計と実装を改善した話
mototakatsu
0
210
Spring Security 実践 ─ GraphQL APIで実務に役立つ 認証・認可 を学ぶ
wagyu
0
250
Oxcを導入して開発体験が向上した話
yug1224
4
320
フロントエンドとバックエンドで「1文字」を揃えよう
youkidearitai
PRO
0
720
セキュリティの専門家じゃなくてもできる。「セキュリティ意識」をアップデートして サプライチェーン攻撃への耐性を高めよう。
tk3fftk
5
890
なぜ型を書くのか? TSKaigi2026で改めて考える #tskaigi_smarthr
kajitack
0
100
CSC307 Lecture 17
javiergs
PRO
0
320
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
410
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1.4k
Odyssey Design
rkendrick25
PRO
2
700
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.1k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
220
The Curious Case for Waylosing
cassininazir
1
400
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 は巨大すぎましたね。 ▶ 派生でそれぞれ議論