5

パッケージ A と B があり、どちらにも独自の git リポジトリ、PyPI ページなどがあります。パッケージ A はパッケージ B に依存しており、install_requiresキーワードを使用することで、A に B を自動的にダウンロードしてインストールさせることができます。

しかし、特に知識のないユーザーのために、さらに一歩先に進みたいとします。パッケージ A の tar/zip 内にパッケージ B を実際に含めたいので、ダウンロードは必要ありません (これにより、パッケージ B を手動で編集できる可能性もありますsetup.cfg) 。

提案された(理想的には自動化された)方法はありますか?

  • sdistA を呼び出すときに B をAに含める
  • 依存関係を解決するために B が A にバンドルされていることを setuptools に伝えます ( local のようなものdependency_links)

ありがとう!

4

1 に答える 1

0

これは「ベンダー化」と呼ばれ、いいえ、そのようなアプローチに対するサポートはありません。

これも悪い考えです。依存関係だけでなく、どのバージョンがインストールされるかを管理する専用ツールにインストールを任せたい場合。buildoutpip の requirements.txt 形式などのツールを使用すると、使用されているバージョンを非常に正確に制御できます。

依存関係のバージョンを内部にバンドルすることにより、ユーザーに使用するバージョンを強制するか、そのようなツールが特定のインストールで使用されるバージョンの一貫性を確保するのを難しくします。さらに、帯域幅とスペースを浪費する可能性があります。他のパッケージにも同じ要件が含まれている場合は、複数のコピーがあります。また、重大なセキュリティ問題を修正するために依存関係が更新された場合は、それをバンドルするパッケージを再リリースする必要があります。

過去に、一部のパッケージはベンダー化パッケージを使用して、依存関係をディストリビューションに含めていました。requestsが代表的な例でした。リリースプロセスが複雑になったため、彼らはこのアプローチから離れました。たとえば、ベンダーが提供するパッケージの 1 つにバグが発生するたびに、修正を含む新しいリリースを作成する必要がありました。

パッケージを含めることに固執したい場合は、独自のサポートを作成する必要があります。requestsベンダー化されたパッケージをリポジトリに手動で追加しただけだと思います。そのため、彼らは時々更新する静的コピーを保持していました。setup.pyまたは、ディストリビューションを作成するときにコードをダウンロードするように拡張することもできます。

于 2012-07-29T09:37:03.963 に答える