ホーム Poetryロゴ

よくある質問（FAQ）

よくある質問（FAQ） #

依存関係の解決プロセスが遅いのはなぜですか？ #

Poetryの中核にある依存関係解決器は高度に最適化されており、ほとんどの場合で十分な速度であるべきですが、特定の依存関係のセットでは、有効な解決策を見つけるのに時間がかかる場合があります。

これは、PyPI上のすべてのライブラリがメタデータを適切に宣言しているわけではなく、そのため、PyPI JSON APIを介して利用できないという事実によるものです。この時点で、Poetryはパッケージをダウンロードして検査して必要な情報を取得する以外に選択肢がありません。これは帯域幅と時間の両方において高価な操作であるため、このプロセスが長いように見える理由です。

現時点では回避策はありません。ただし、Poetryが単一のパッケージの多くのバージョンをダウンロードしていることに気付いた場合は、pyproject.tomlでそのパッケージをより狭く制約することで、ワークロードを軽減できます。そうすることで、Poetryは多くのバージョンをふるいにかける必要がなくなり、場合によってはロックプロセスを大幅に高速化できる可能性があります。

注記
Poetryがリリースの情報をマシンにキャッシュしたら、依存関係の解決プロセスははるかに高速になります。

Poetry自身は何種類のバージョン管理スキームを使用していますか？ #

Poetryは、PEP 440で述べられているように、「メジャー.マイナー.マイクロ」のバージョン識別子を使用しています。

バージョンの更新は、Pythonのバージョニングと同様に行われます。

  • メジャーバージョンの更新（最初の数値の増加）は、非推奨サイクルが不可能であり、多くのユーザーがバージョン間を移行するためにいくつかの手動手順を実行する必要がある場合にのみ、破壊的変更に対して行われます。
  • マイナーバージョンの更新（2番目の数値の増加）には、新しい機能に加えて、新しい非推奨および以前のマイナーリリースで非推奨になった機能の削除が含まれる場合があります。
  • マイクロバージョンの更新（3番目の数値の増加）には、通常、バグ修正のみが含まれます。非推奨の機能は、マイクロリリースでは削除されません。

Poetryがセマンティックバージョニングに従わないのはなぜですか？ #

大規模なユーザーベースがあるため、ほとんどのユーザーにとって重要とは考えられない小さな変更でも、後になって一部のユーザーにとって破壊的変更になる可能性があります。厳格なセマンティックバージョニングを遵守し、マイナーバージョンではなくメジャーバージョンを常に（ほぼ）更新することは、マイナーバージョンがもはや意味を持たなくなるため、望ましくありません。

上限のないバージョン制約は悪い考えですか？ #

*や>=3.4などの上限のないバージョン制約は、依存関係の将来の任意のバージョンへの更新を許可します。これには、下位互換性を壊すメジャーバージョンも含まれます。

パッケージのリリースが公開された後、依存関係がBCを壊した場合、依存関係を調整することはできなくなります。新しいリリースを行う必要がありますが、以前のリリースは壊れたままです。（ユーザーは、自分で制限することで、壊れた依存関係を回避できます。）

このような問題を回避するために、制約の上限を定義できます。これは、パッケージが依存関係の新しいメジャーバージョンと互換性があることをテストした後、新しいリリースで増やすことができます。

たとえば、>=3.4を使用する代わりに、^3.4を使用できます。これは、すべてのバージョン<4.0を許可します。^演算子は、セマンティックバージョニングに従っているライブラリで非常にうまく機能します。

ただし、上限を定義すると、ユーザーは、何も壊れておらず、パッケージと完全に互換性がある場合でも、上限を超えて依存関係を更新できません。上限を増やしたパッケージの新しいバージョンをリリースする必要があります。

パッケージが他のパッケージでライブラリとして使用される場合、不要な依存関係の競合を回避するために（依存関係の次のリリースがパッケージを壊すことがすでにわかっている場合を除き）、上限を回避する方が良い場合があります。パッケージがアプリケーションとして使用される場合、上限を定義する価値があります。

toxはサポートされていますか？ #

はい。tox >= 4を使用している場合、Poetryによって提供されるPEP 517準拠のビルドシステムと組み合わせて使用できます。（tox 3では、isolated buildオプションを設定する必要があります。）

そのため、pyproject.tomlファイルに、まだ存在しない場合はこのセクションを追加します。

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

toxは複数の方法で設定できます。テスト対象のコードとインストールする依存関係によって異なります。

ユースケース＃1 #

[tox]

[testenv]
deps =
    pytest
commands =
    pytest tests/ --import-mode importlib

toxはプロジェクトのsdistパッケージを作成し、pipを使用して新しい環境にインストールします。したがって、依存関係はpipによって解決されます。

ユースケース＃2 #

[tox]

[testenv]
allowlist_externals = poetry
commands_pre =
    poetry install --no-root --sync
commands =
    poetry run pytest tests/ --import-mode importlib

toxはプロジェクトのsdistパッケージを作成し、pipを使用して新しい環境にインストールします。したがって、依存関係は最初にpipによって解決されます。しかし、その後、Poetryを実行し、ロックされた依存関係を環境にインストールします。

ユースケース＃3 #

[tox]

[testenv]
skip_install = true
allowlist_externals = poetry
commands_pre =
    poetry install
commands =
    poetry run pytest tests/ --import-mode importlib

toxはインストールを実行しません。Poetryは、すべての依存関係と現在のパッケージを編集可能なモードでインストールします。したがって、テストはビルドおよびインストールされたパッケージではなく、ローカルファイルに対して実行されます。

資格情報に関する注記 #

tox はデフォルトでは現在のシェルセッションの環境変数を転送しません。Linuxシステムでシステムキーリングを使用して資格情報を設定した場合、または一般的に環境変数を使用している場合、これにより、tox 環境で Poetry が依存関係をインストールできなくなる可能性があります。必要な変数を明示的に転送するには passenv 設定オプション を使用するか、すべて転送するには passenv = "*" を使用します。システムキーリングへのアクセスを許可するには、Linuxシステムでは DBUS_SESSION_BUS_ADDRESS 変数の転送が必要になる場合がありますが、これはデスクトップ環境によって異なる場合があります。

または、キーリングを完全に無効にすることもできます。

poetry config keyring.enabled false

これは、Poetry がパスワードをプレーンテキストの構成ファイルに書き込む原因となることに注意してください。この設定を変更した後、資格情報を再設定する必要があります。

Nox はサポートされていますか？ #

nox-poetry パッケージを使用して、poetry.lock に指定されている依存関係のロックされたバージョンを Nox セッションにインストールします。

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

Poetry はグローバルな Python インストールから常に分離して動作するように仮想環境を自動的に作成しますが、Poetry が管理する仮想環境の使用が不可能または好ましくないまれなシナリオがあります。

この場合、virtualenvs.create 設定を false に設定することで、この機能を無効にできます。

poetry config virtualenvs.create false
警告

コンテナ内でアプリケーションをインストールする場合も含め、推奨されるベストプラクティスは、仮想環境を使用することです。これは他のツールで管理することもできます。

Poetry チームは、仮想環境の使用を強く推奨しています。

なぜ Poetry は、現在のプロジェクトでサポートされている Python の範囲が、1 つ以上のパッケージの Python 要件と互換性がないことを通知するのですか？ #

pip とは異なり、Poetry は現在の環境の Python だけについて解決しません。代わりに、pyproject.toml に指定された Python バージョン範囲内で依存関係が解決可能であることを確認します。

次の pyproject.toml があると仮定します。

[tool.poetry.dependencies]
python = "^3.7"

これは、プロジェクトが Python バージョン >=3.7,<4.0 との互換性を目指していることを意味します。依存関係の Python 要件が範囲全体と一致しない依存関係を追加しようとすると、Poetry はそれを通知します（例：）。

The current project's supported Python range (>=3.7.0,<4.0.0) is not compatible with some of the required packages Python requirement:
    - scipy requires Python >=3.7,<3.11, so it will not be satisfied for Python >=3.11,<4.0.0

通常、プロジェクトのサポートされている Python の範囲と、失敗した依存関係の上限を一致させたいでしょう。または、特定の Python バージョン範囲でのみ この依存関係をインストールするように Poetry に指示することもできます（すべてのバージョンで必要ないことがわかっている場合）。

なぜ Poetry は PEP 440 バージョンを強制するのですか？ #

これは、より広範な Python エコシステムとの互換性を保つためです。

たとえば、PEP 440 に従って有効でないバージョンを使用するプロジェクトの配布物を Poetry がビルドした場合、サードパーティツールはバージョンを正しく解析できません。

サードパーティの依存関係をインストールする前にソースファイルをコピーする必要があるため、Poetry によって Docker キャッシュが破損します #

デフォルトでは、poetry install ... を実行するには、ソースファイル（「ルート」パッケージと、存在する可能性のあるディレクトリパス依存関係の両方）が存在する必要があります。これは、ソースファイルの変更によってレイヤー（Dockerfile の後続のコマンド）が再実行されるため、Docker のキャッシュメカニズムと相互作用が悪くなります。たとえば、次のような Dockerfile があるとします。

FROM python
COPY pyproject.toml poetry.lock .
COPY src/ ./src
RUN pip install poetry && poetry install --only main

ソースファイルが変更されると、RUN レイヤーのキャッシュが無効になり、src/ のファイルが変更された場合、すべてのサードパーティの依存関係（おそらくこれらの中で最も遅いステップ）が再度インストールされます。

このキャッシュの破損を回避するには、次の 2 つのステップに分けることができます。

  1. サードパーティの依存関係をインストールします。
  2. ソースコードをコピーし、ソースコードだけをインストールします。

これは次のようになります。

FROM python
COPY pyproject.toml poetry.lock .
RUN pip install poetry && poetry install --only main --no-root --no-directory
COPY src/ ./src
RUN poetry install --only main

ここで使用している 2 つの重要なオプションは、--no-root（プロジェクトソースのインストールをスキップ）と --no-directory（ローカルディレクトリパス依存関係のインストールをスキップ、ローカルディレクトリ依存関係がない場合は省略できます）です。poetry installで使用可能なオプションの詳細。

リクエストのタイムアウトが発生しています！ #

Poetry のデフォルトの HTTP リクエストタイムアウトは 15 秒で、pip と同じです。PIP_REQUESTS_TIMEOUT と同様に、実験的な環境変数 POETRY_REQUESTS_TIMEOUT を設定してこの値を変更できます。