MENU

Poetryとは Pythonの依存解決とビルドを統合するツール

Poetry アイキャッチ
Poetry

Poetryは2018年2月にSébastien Eustaceが公開したPython向けプロジェクト管理ツールで、依存解決、ロックファイル生成、仮想環境管理、wheel/sdistビルド、PyPI公開を単一のCLIで統合する。pyproject.toml一本に設定を集約する設計はその後のPython標準化の流れに大きく影響を与えた。本稿ではPoetryのリゾルバの特徴、ワークフロー、CIでの使い方、競合ツールとの差異を順に整理する。

目次

この記事の目次

  1. Poetryが解決する範囲
  2. 依存リゾルバの仕組み
  3. CIとモノレポでの実用
  4. 競合ツールとの位置取り
  5. まとめ

Poetryが解決する範囲

Poetryが解決する範囲

PoetryはComposer(PHP)やCargo(Rust)に強く影響を受けており、従来のPythonでpip, setuptools, twine, virtualenvに分割されていた役割を1コマンドに統合した。poetry add requests でpyproject.tomlへ依存を追記しつつインストールまで完了する設計は、yarn addやcargo addを使ってきた開発者にとって自然なUXとして好評を得た。また自動で.venvを管理するため、virtualenvの活性化を意識せずに開発を進められる。

ビルド機構としてはpoetry-coreというPEP 517互換のbackendを別パッケージで切り出しており、ビルド時にPoetry CLI全体を依存させないよう設計されている。これによりCIでwheelを作る場合、pip install poetry-coreだけで済み、ビルド時間とコンテナ容量を抑えられる。PoetryはCLIとビルドbackendを分離した最初期の例で、Hatchling, flit_coreなど後続backendも同じ思想を踏襲している。

依存リゾルバの仕組み

依存リゾルバの仕組み

PoetryのリゾルバはPubGrub(Dart pubで使われているアルゴリズム)を参考にしたバックトラック型で、決定論的な解を返すよう設計されている。pip 20.3で導入された新リゾルバも同じくバックトラック型だが、Poetryは依存関係に矛盾があったときの説明メッセージが「Aを要求するからBを試したが、CがBを許さない」といった人間可読な形で出力される点で評価が高い。依存ツリーが深いプロジェクトでは数十秒の探索になることもあるが、解は再現可能だ。

poetry.lockはハッシュ付きの完全なバージョン固定ファイルで、poetry install --no-update を使う限り別マシンでも同一の依存が再現される。lockをgit管理しCIで同一性を検証する運用は、JavaScriptのyarn.lockやRustのCargo.lockと同じ思想に基づく。lockが古くなった場合はpoetry lock --no-updateで構造を保ったまま再計算でき、pyproject.tomlに矛盾があれば失敗するためレビューで弾きやすい。

CIとモノレポでの実用

CIとモノレポでの実用

CIで使う際の定石は、まずpipxまたは公式インストーラでpoetryを導入し、poetry install --no-interaction --no-root でアプリ自身を除いた依存だけを取り込む方法だ。lockのハッシュキャッシュをGitHub ActionsのactionsCache等に保存しておけば、次回ビルド時の依存解決を完全にスキップでき、Pythonジョブを数分単位で短縮できる。本番コンテナへはpoetry export -f requirements.txt --without-hashes=false で出力しpip installする構成が一般的だ。

モノレポ運用ではPoetry 1.2で導入されたpath dependencyとgroup機能が要となる。[tool.poetry.group.dev.dependencies]のようにグループを分け、開発用、ドキュメント用、テスト用の依存を分離できるため、本番イメージには必要最小限だけを入れて軽量化できる。またpoetry.lockをモノレポのルートに1つ持つ集中型と、サブパッケージごとに持つ分散型の選択が可能で、大規模プロジェクトでは後者が選ばれることが多い。

競合ツールとの位置取り

競合ツールとの位置取り

Poetryは長らくPython依存管理のデファクトとして使われてきたが、2018年から2022年頃まではpyproject.tomlの[tool.poetry]節が独自仕様だった点が議論を呼んだ。後のPEP 621で[project]節が標準化されたとき、Poetryは互換のために両方を許す方向で対応している。2.0系では[project]節を一次データソースとし、Poetry独自フィールドを補助に位置付ける流れが固まりつつある。

2024年2月のAstral社によるuvリリース以降、競合状況は大きく変わった。uvはRust実装で依存解決とインストールを劇的に高速化し、Poetryでは数十秒かかる解決を1秒以下で済ませる場合もある。またRustacean Eric ChiangらがryeをuvにマージしたことでPython版管理機能も統合された。Poetryは安定性と豊富なエコシステム、丁寧なエラーメッセージで依然優位を保つが、新規プロジェクトではuvを採用する事例が急速に増えている。

まとめ

Poetryは2018年に登場して以降、依存解決とビルドを一体化したPython開発のスタンダードを築いてきた。PubGrub系の明快なリゾルバ、poetry.lockによる再現性、PEP 517 backendの分離設計は今なお価値が高く、uv等の新興ツールと組み合わせて選定する際の比較基準として理解しておく意義は大きい。

※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次