穀風

Python で pip install 可能なパッケージを作成した際、 PyPI に登録してしまえば pip が適切に処理してくれるので簡単です。

しかし、内部用のライブラリの場合は明示的にリポジトリの場所を指定しなければなりません。 そのための機能として、setuptools.setup() には dependency_links という引数があります。

ところが、pip install しようとした場合、dependency_links は無視されてしまい、うまくいきません。 dependency_links は、基本的に python setup.py install の場合を想定しているようです。

ただ、pip は setup.py の上位ラッパー¹のはず。 対処方法が無いはずはないと思って調べてみました。

普通に pip install するとエラーが発生する

まずはエラーが発生する状況を説明します。

例として、インハウスレポジトリ myserver.com に登録してある mytestlib というパッケージを想定します。

この時、mytestlib を使用するアプリケーション(mytestapp)の setup.py は以下のようになります。

これを以下のように pip を使ってインストールしようとすると、"Could not find a version that satisfies the requirement mytestlib==0.1" とエラーが発生してしまいます。

解決法1 --process-dependency-links を使う

pip install に --process-dependency-links をつけると以下のようにインストール可能です。

ただ、よく見てみると DEPRECATION: Dependency Links processing has been deprecated and will be removed in a future release. との警告が。 --process-dependency-links は将来的には無くなる可能性があるわけです。

この DEPRECATION、有効な代替手段が無いようで、DEPRECATION 自体を取りやめるべきだという議論も起きています。

参考

Un-deprecate --process-dependency-links until an alternative is implemented · Issue #4187 · pypa/pip · GitHub

現時点では確実なことは言えませんが、DEPRECATION が取りやめになるか、他に有効な代替手段が提供されるのではないかと思います。

解決法2 --find-links を使う

多分、--process-dependency-links の正統な代替手段なのだと思われます²。

以下のように、pip の実行時に信頼できるパッケージを列挙します。 この時、setup.py 内の dependency_links は無くてもかまいません。

参考

Python: PyPI にないパッケージを依存パッケージにするには - CUBE SUGAR CONTAINER

この方法、確かに動作するのですが、依存パッケージの数が増えてくると手間がかかりすぎてしまいます³。

また、mytestlib パッケージの中でさらに dependency_links が書かれている場合、それも --find-links で指定しなければなりません。 依存関係が複雑になってきた場合、これは現実的とは言えません。

解決法3 setup.py install を使う

以下のように一度 clone してから、python setup.py install すると dependency_links が適切に処理されます。

しかし、この方法、せっかく登場した pip の恩恵が受けられません。特に mytestlib パッケージの中でさらに dependency_links が書かれている場合はそれが適切に処理されません。 これは、--find-links と同様の問題です。

参考

virtualenv - Difference between 'python setup.py install' and 'pip install' - Stack Overflow

解決法4 --requirement を使う

この方法は解決法とは言えないのですが、一応書いておきます。

まず、以下のような requirements.txt を用意します。

pip --requirement に先の requirements.txt を指定すればインストール可能です。

この --requirement、そもそも特定の環境をフリーズして別の場所で再現させることを目的とした機能なので、このように使うのが適切とは思えません。

さらに、この方法も mytestlib パッケージがさらに内部ライブラリに依存している場合、それらを自分で requirements.txt に列挙しなければなりません⁴。

結局、どの方法を使うべきか

上記4つの方法の中で、多段の依存関係を適切に処理できるのは「解決法1 --process-dependency-links を使う」だけです。

そのため、現時点では --process-dependency-linksを使っておくのが良いだろうと思います。 DEPRECATION の警告が出るのが気になるところですが、議論の様子からすると、他に有効な代替手段が出てこない限り削除されることは無いのではないでしょうか。

しばらくは、--process-dependency-links を使いながら、議論の行方を注意深く見守るのが良いのだろうと思います⁵。