FAQ🔗

なぜ依存関係解決の処理は遅いのですか？🔗

Poetryの心臓部である依存関係解決器は大いに最適化されており、ほとんどのケースで十分に速いはずですが、ときどき、ある依存関係の特定の組み合わせでは、妥当な解決策を見付けるのに時間がかかることがあります。

これは、PyPIにある全てのライブラリが適切なメタデータの宣言をしているわけではなく、それらはPyPI JSON APIからは利用可能でないという事実に依るものです。現時点では、パッケージをダウンロードし、中身を調べて必要な情報を取得する以外の選択肢は、Poetryにはありません。これは手間の掛かる作業で、それが原因でバンド幅と時間の両方において長い処理に見えるのです。

今のところ、これを回避する道はありません。

注意

いったんPoetryがリリース情報をキャッシュしてしまえば、依存関係解決の処理はとても速くなります。

上限の無いバージョン制約が良くないのはなぜですか？🔗

* や >=3.4 のような上限の無いバージョン制約は、依存関係のいくらでも先のバージョンへの更新を許可します。これには後方互換性を破壊するメジャーバージョンも含まれています。

いったんパッケージのリリースが公開されてしまうと、後方互換性の破壊が起きてしまうケースでも、それ以降は依存関係の微調整は行えなくなります。そうなると新しいリリースを出さなればいけませんが、その前のリリースは後方互換性が壊れたままです。

唯一の適切な選択肢は、バージョン制約に上限を設け、パッケージが依存関係の新しいメジャーバージョンと互換性があることをテストした後の新しいリリースで、その上限を上げられるようにすることです。

例えば、 >=3.4 を使う代わりに、 <4.0 を満たす全てのバージョンを許可する ~3.4 を使うべきです。 ^ 演算子は、セマンティックバージョニングに従ったライブラリと非常に相性が良いです。

toxはサポートしていますか？🔗

はい。 tox が提供している隔離ビルドを使うことで、Poetryが提供するPEP 517準拠のビルドシステムと tox を連携して使えます。

連携させるには、 pyproject.toml ファイルに、この節がまだ無ければ追加してください:

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

そして、このような tox.ini 設定ファイルを使ってください:

[tox]
isolated_build = true
envlist = py27, py36

[testenv]
whitelist_externals = poetry
commands =
    poetry install -v
    poetry run pytest tests/

Poetryに仮想環境を管理されたくありません。無効化できませんか？🔗

Poetryは、グローバルにインストールされたPythonから隔離された状態で動作するために仮想環境を自動的に作成しますが、コンテナで動作させるときのような、その必要が無くむしろオーバーヘッドになるという、そうしない妥当な理由もあります。

このケースでは、 virtualenvs.create に false を設定することで、この機能を無効化できます:

poetry config virtualenvs.create false