Python パッケージを開発する際、同じ依存関係の異なるバージョンが必要な場合、ユーザーは依存関係の競合に遭遇する可能性があります。たとえば、パッケージにはrequests==2.26.0が必要だが、ユーザーのシステムにはrequests==2.25.1が必要な場合、Pythonでは同じパッケージの複数のバージョンを同時にインストールすることができないため、両方は共存できません。
依存関係の競合を回避するアプローチ:
A. ベンダーのアプローチ:
-
依存関係のベンダー: これには、必要な依存関係をパッケージに直接含めることが含まれます。バージョンを管理するのに便利ですが、パッケージのサイズが増加する可能性があります。
-
純粋な Python パッケージ: ベンダーは、独自の依存関係のない純粋な Python パッケージに対して適切に機能します。
-
依存関係のあるパッケージ: ベンダー化されたパッケージに独自の依存関係がある場合、ベンダー化に問題が発生し、潜在的な競合が発生します。
問題:
-
依存関係の衝突: 依存関係を含むパッケージをベンダーすると、ユーザーの環境で競合が発生する可能性があります。
-
バージョン管理: ベンダーの依存関係を最新の状態に保つことは、セキュリティにとって非常に重要です。
-
サイズ: ベンダーによってパッケージのサイズが大きくなる可能性があります。
例:
-
シナリオ 1: リクエストに依存関係がない場合、リクエストをパッケージにバンドルすると、正しいバージョンが使用されるようになります。
-
シナリオ 2: リクエストは urllib3 などのライブラリに依存しているため、これを含めると、他のパッケージが異なるバージョンの urllib3 を必要とする場合に競合が発生する可能性があります。
注: ベンダーを行う場合は、ベンダー ポリシーに準拠する必要があります。こちらからご確認ください。
B. 仮想環境アプローチ:
- 依存関係の競合は、仮想環境が使用されている場合でも、特にサードパーティのアプリでは制御できないことがよくあります。
問題:
-
当社の制御外: ユーザーが仮想環境をどのように設定するかは、当社の影響力を超えています。
-
サードパーティ アプリ: 仮想環境であっても、依然として競合の問題に直面する可能性があります。
C. フォークアプローチ:
- 競合するパッケージをフォークし、名前を変更し (例: mypackage-requests==2.26.0)、フォークしたバージョンをパッケージ内で使用できます。
問題:
-
メンテナンス: フォークには、元のパッケージでフォークを最新の状態に保つ必要があります。
-
子の依存関係: フォークされたパッケージに依存関係がある場合は、それらもフォークして管理する必要がある場合があります。
結論:
それぞれのアプローチには利点と課題があり、選択は特定のユースケースと依存関係をどの程度制御したいかによって異なります。経験則として、パッケージを適切に維持し、より広範な Python エコシステムとの互換性を確保することで競合を解決することをお勧めします。
リソース:
- requirements.txt 内の競合するパッケージはどのように管理しますか?
- 販売ポリシー
- python-vendorize
- ベンダーのパッケージについてどう思いますか?
以上がPython パッケージの競合の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。