Poetryの1.2以上のリリースを追う
Poetry1.2系でfasttextをinstallすることができないことが原因でかなり詰まってしまった。
Poetryは最近かなりアップデートを重ねているので、この機にPoetryの1.2以降の変更で何が入っているかを理解したい。
関連issue: https://github.com/python-poetry/poetry/issues/6113
⚠️以下のコメントは、ChatGPT Pluginを使って、サイトの内容を要約してもらったもの。
自分が読みつつチェックしているものの、不整合な点があるかもしれないです。
Summary
- 1.2.0の変更
- poetry自体のインストーラーが変更された
- 2系, 3.5,3.6のサポート終了
- poetry pluginの追加
- (要確認) PEP517を満たさないライブラリのインストールができなくなった...?
- 1.3.0
- ロックファイルの形式変更
- キャッシュの破壊を防ぐ機構が追加
- 1.4.0
- インストーラーの高速化
- パス依存性の検証が、パス依存性を考慮する必要があるときのみに実行されるようになる
Announcing Poetry 1.2.0
2022/08あたりのリリース
ChatGPTの解説
Pythonの依存関係管理とパッケージ化を容易にするPoetryの新バージョン1.2.0のリリースを発表しています。この新バージョンは、過去2年間にわたって開発された多数の変更、新機能、修正が含まれています。
主な変更点としては以下の通りです:
-
新しいスタンドアロンインストーラー:従来のget-poetry.pyインストールスクリプトがinstall.python-poetry.orgに置き換えられました。新しいインストーラーは独立したプロジェクトとして、独自の問題追跡システムを持っています。
-
Python 2.7プロジェクトの管理サポートの削除:Python 2.7は2020年1月1日にサポート終了しました。Poetry 1.2はPython 2.7プロジェクトの管理サポートを削除しました。
-
Python 2.7、3.5、3.6のランタイムサポートの削除:Poetry 1.2はPython 2.7、3.5、3.6のランタイムサポートを削除しました。これらのバージョンでPoetryを実行することは、テストされておらずサポートされていません。
-
依存関係グループ:Poetryは依存関係をグループ化する方法を提供します。たとえば、プロジェクトをテストするためだけに必要な依存関係や、ドキュメンテーションを作成するためだけに必要な依存関係などがあります。
-
プラグインサポート:Poetryは、機能を変更または拡張するための実験的なプラグインシステムをサポートしています。
-
Migration of the poetry export command:
export
コマンドは、ロックされた依存関係のリストを他の形式(例えばrequirements.txt
)にエクスポートする方法を提供します。このコマンドはPoetryへの移行を容易にするために追加された機能でしたが、Poetryのコア機能の一部とは見なされていませんでした。これを反映して、主要なPoetryプロジェクトの開発を加速するために、このコマンドは別のリポジトリに移行され、poetry-plugin-export
として別途配布されるようになりました。なお、これは独立したプロジェクトと見なされ、独自の問題追跡システムとリリースサイクルを持っています。 -
Other noteworthy changes and features: 以下にその他の注目すべき変更と新機能をいくつか挙げます:
-
PEP 592による引き上げられたリリースのサポート: PoetryはPEP 592により定義された引き上げられたリリースをサポートしています。これはPyPIと任意のPEP 503互換リポジトリの両方に適用されます。
-
PEP 610によるDirect Origin URLレコードのサポート: PoetryはPEP 610レコードの読み書きをサポートしています。これにより、インストールされた依存関係の起源を決定する際のエッジケースとパフォーマンス問題が解決されます。
-
Git依存関係のサブディレクトリサポート: Poetryは、Gitベースの依存関係をビルドしてインストールするためのサブディレクトリを指定することが可能になりました。
-
シングルページリポジトリサポート: Poetryは、'シングルページ'スタイルのリポジトリから依存関係を発見し、インストールすることをサポートしています。
-
ロックファイルと環境の同期: 環境がロックファイルと完全に一致することを確認するために、
install
コマンドに新しい--sync
フラグが追加されました。 -
バイナリ配布のオプトアウト: バイナリ配布の選択的な依存関係をオプトアウトするために、新しい
installer.no-binary
設定が導入されました。 -
ネイティブPython依存関係のサポート: Poetryは、ネイティブPython依存関係(つまり、Python以外の言語で書かれたライブラリに依存するPythonパッケージ)をサポートしています。これにより、Poetryはより広範なPythonプロジェクトの依存関係管理を可能にします。
-
Announcing Poetry 1.3.0
2022/12あたりのリリース。
「Poetry 1.3.0」の発表についてのブログ記事は、Pythonの依存関係管理とパッケージ化を容易にするPoetryの新バージョン1.3.0のリリースを発表しています。
主な変更点としては以下の通りです:
-
新しいロックファイル形式:ロックファイルの形式が変更され、明示的なソースをより良くサポートします。この変更はユーザーにとってほとんど透明で、Poetry 1.2.2以降は新しい形式を読むことができ、Poetry 1.3.0は以前のロックファイル形式の読み取りを完全にサポートしています。
-
キャッシュの破損を防ぐ:Poetry 1.1と1.2は、以下の一般的なシナリオでさまざまなキャッシュを破損させる可能性がありました:PyPIからメタデータを収集している間にPoetryのインスタンスを中断する、アーティファクトキャッシュに対して同時にPoetryのインスタンスが書き込む(例:poetry install、poetry updateなど)。これらの問題はPoetry 1.3で修正されています。
-
generate-setup-file = false:Poetryは長い間、古いバージョンのpipとの互換性のためにスタブのsetup.pyファイルを生成してきました。次のPoetryのマイナーリリースでは、この動作が逆転し、デフォルトでsetup.pyの生成がオフになります。
その他にも多くの新機能や改善が行われています。詳細な変更リストはプロジェクトの履歴を参照してください。
Announcing Poetry 1.4.0
2023/02のリリース
「Poetry 1.4.0」の発表についてのブログ記事は、Pythonの依存関係管理とパッケージ化を容易にするPoetryの新バージョン1.4.0のリリースを発表しています。
主な変更点としては以下の通りです:
-
パッケージのインストール速度向上:Poetry 1.4では、新しいモダンなインストーラーが導入され、デフォルトで有効になっています。新しいインストーラーはpipから独立しており、特にパッケージがすでにキャッシュされている場合、以前のデフォルトのインストーラーよりも高速です。新しいインストーラーはデフォルトでバイトコードをコンパイルしないため、インストール時にバイトコードをコンパイルするには
poetry install --compile
を実行します。問題が発生した場合、installer.modern-installation
をfalse
に設定することで新しいインストーラーを無効にすることができます。 -
パス依存性の検証の変更:パス依存性はもはや構築時には検証されず、使用時にのみ検証されます。つまり、インストールの対象とならないグループに含まれている場合、パス依存性は検証されません。また、
poetry lock --no-update
はもはやリネームされたパス依存性について失敗しません。 -
generate-setup-file = false:Poetryは長い間、古いバージョンのpipとの互換性のためにスタブのsetup.pyファイルを生成してきました。Poetry 1.4では、この動作が逆転し、デフォルトでsetup.pyの生成がオフになります。この変更はほとんどのユーザーにとって透明で、代替ビルドシステムをネイティブにサポートするpipのバージョンがほぼ4年間利用可能であったためです。
その他にも多くの新機能や改善が行われています。詳細な変更リストはプロジェクトの履歴を参照してください。
パス依存性とは?
パス依存性とは、あるPythonパッケージが他のPythonパッケージに依存しているが、その依存パッケージがPyPI(Python Package Index)などの公開されたパッケージリポジトリではなく、ローカルファイルシステム上の特定のパスに存在する場合の依存関係を指します。
Poetryでは、pyproject.tomlファイルの[tool.poetry.dependencies]セクションでパス依存性を定義することができます。
[tool.poetry.dependencies]
my-library = { path = "../my-library/" }
なぜpoetry1.2系でfasttextをinstall時に落ちるようになったのか?
おそらく、https://github.com/python-poetry/poetry/pull/3835 の変更によるもの
1.2.0a にてPoetryのライブラリinstall時にPEP517のビルドシステムをdefaultで使用するようになったから。
これはhttps://github.com/python-poetry/poetry/pull/2826 にてpoetry1.2系ではがpipとsetuptoolsへの依存性を削除し、PEP 517に準拠したビルドプロセスを採用したため。
PEP517とは?
PEP 517は、Pythonのパッケージングシステムに関する提案で、Pythonのパッケージビルドプロセスをより柔軟にするためのもの。
PEP 517は、Pythonのパッケージングシステムにおけるビルドバックエンドとフロントエンドの間のインターフェースを定義します。これにより、パッケージのビルドプロセスが標準化され、異なるビルドシステム間での互換性が向上します。
具体的には、PEP 517は以下のような機能を提供します:
- パッケージのビルドプロセスをカスタマイズするためのフック(ビルドバックエンドが提供)
- ビルドバックエンドを指定するための新しい設定ファイル
pyproject.toml
- ビルドバックエンドとしてsetuptoolsやflitなどを使用することが可能
これにより、Pythonのパッケージングシステムはより柔軟性と互換性を持つことができ、パッケージのビルドと配布が容易になります。
なぜpipとsetuptoolsへの依存性を削除するべきなのか?
Pythonのパッケージングエコシステムは長い間、setuptools
とpip
に大きく依存してきました。これらのツールは非常に強力で、Pythonのパッケージングと配布の基盤となっています。しかし、この依存性にはいくつかの問題点があります。
-
柔軟性の欠如:
setuptools
とpip
に依存していると、これらのツールがサポートしているビルドと配布の方法に制限されます。他のツールを使用してパッケージングプロセスをカスタマイズしたい場合、それが困難になる可能性があります。 -
互換性の問題:
setuptools
とpip
のバージョン間には互換性の問題があることがあります。これらのツールの新しいバージョンがリリースされると、既存のパッケージが壊れる可能性があります。 -
依存性の地獄:
setuptools
とpip
は他の多くのパッケージに依存しています。これらの依存パッケージが互いに異なるバージョンを要求すると、依存性の解決が困難になることがあります。
これらの問題を解決するために、PEP 517とPEP 518はpyproject.toml
という新しい設定ファイルを導入しました。これにより、パッケージのビルドに必要なツールとそのバージョンを明示的に指定できるようになりました。これにより、パッケージのビルドプロセスはより予測可能で、カスタマイズ可能になりました。