これまで依存パッケージ管理で遅れをとっていた Python ですが、Pipenv というモダンなツールが定着の兆しをみせており、Python エンジニアの一人として非常に喜ばしく感じています。
一方で、Go を使うことも多い自分にとっては、依存パッケージ管理に加えて Vendoring もやりたいというのが正直なところなんですよね。リッチな機能を提供する Pipenv ですが Vendoring についてのサポートはなく、開発コミュニティ上でもあまり積極的に受け入れられていないようです。
私のような考え方はマイノリティなのかもしれませんが、後述するように Python でも Vendoring が出来ればいくつかのメリットがあります。という訳で実現するためにはどうすればよいかというところを調べたので、これを共有したいとおもいます！

そもそも Vendoring ってなに？

一般的な依存管理というのは、依存するパッケージとそのバージョンを明記したリストを管理して、メンバーがおのおのの開発環境に依存パッケージをインストールするというアプローチをとりますよね。それに対して Vendoring は、依存パッケージをソースごとプロジェクトに取り込んでしまうアプローチのことです。例えば Go ではこのアプローチは市民権を得ていて、dep, glide といったメジャーな依存管理ツールでサポートされています。

最初にこのアプローチを聞いたとき、正直なところ私は若干の抵抗がありました。「リポジトリからすぐに取ってこれるものを、プロジェクト内で抱えるのは冗長ではないか？」というところです。しかし、よくよく考えてみるとこのアプローチを取るのが一番安全で、最近ではむしろ合理的なんじゃないかとすら感じるようになりました。

Vendoring ってなにが嬉しいの？

パッケージの開発者目線から見てもユーザ目線から見ても、依存性管理が楽になります。

まず、開発者目線から考えると、そのパッケージが実際に利用される環境での再現性が高まることがメリットです。依存パッケージが突然 PyPI から消えてしまったり、同じバージョンで別のパッケージに改変されるということもあり得なくはないです。意識の高い現場では、こういったケースに備えてキャッシュ用の社内 PyPI を立てたり、パッケージを落としてきてファイルサーバ等で別途管理するかと思いますが、Vendoring してしまえばそういった備えが要らなくなります。

また、ユーザ目線から考えてみます。ある Python アプリを使いたいと思って該当パッケージを環境にインストールするとき、多くのエンジニアは環境が汚れることを懸念して仮想環境の作成を検討すると思います。環境が汚れるというのは、将来的に別のパッケージをインストールしたときに、依存パッケージがインストール済みのバージョンと競合してしまって、そのパッケージ自体のインストールが拒否されるという問題に起因します。しかし、全ての依存パッケージを Vendoring すると、パッケージレベルで他パッケージへの依存がない状態になります。その結果、そのパッケージのインストールが将来のインストールに影響することもありませんし、そのパッケージ自体のインストールが拒否されるという心配もありません。つまり、パッケージが Vendoring されていることによって、実質的にインストール先の環境は汚れなくなると言えます。環境が汚れないので、インタプリタのバージョンさえマッチしていれば、もはや仮想環境を作成する必要もありません。

その他にも、依存パッケージが作業ディレクトリ配下におさまることで、依存パッケージのソースへのアクセスがしやすかったり、IDE のインデクシング設定もいくぶん楽になります。

Python で Vendoring なんて出来るの？

実は既存のオープンソースプロジェクトでも、Vendoring を採用しているところがいくつかあります。 特に謳われているわけではないものの、pip プロジェクトはそういったプロジェクトの一つです。

pip プロジェクトのリポジトリをみてみると、src/pip/_vendor というディレクトリがあるのがわかります。これが依存パッケージをソースごとまとめて管理しているディレクトリで、中をみるとパッケージ名のついたディレクトリが並んでいることがわかるとおもいます。そして、注目すべきはvendor.txt とMakefile です。

...（省略）vendor:@# Install vendored librariespipinstall-t.-r vendor.txt@# Cleanup .egg-info directoriesrm-rf*.egg-inform-rf*.dist-info

pip プロジェクトではプロジェクトルートの requirements.txt とは別に Vendoring 用の依存パッケージリスト（vendor.txt）を管理して、そのリストをもとに pip install でソースを専用のディレクトリ配下（src/pip/_vendor）に落としています。
そして、これと同じことをすれば自分のプロジェクトでも Vendoring が出来るわけですね！

※ pip プロジェクトでは、パッケージ自体の依存性を少なくしたいという理由の他に、依存パッケージのソースにパッチあててオリジナルに改変を加えるようなことをやっていて、そのためにソースをプロジェクトごと取り込んでいる背景もあります。ただ理由はどうであれ、Vendoring をやっていることには変わりがないので、採用例として挙げています。

Vendoring はこうやれば導入できるよ

pip プロジェクトという事例から、どうやれば Vendoring 出来るかがわかりました。最後にこれを一般化してまとめようと思います。ついでに、パッケージ管理にはモダンな Pipenv を採用することにします。ちなみに、私が最近書き始めたescher という Python アプリのリポジトリを、Vendoring 導入のサンプルとして利用します。

まず、vendor ディレクトリを作成します。作成するパスはディレクトリ構成にもよるので、各プロジェクトでよさそうなところを決めてください。

mkdirescher/vendor

次に、vendor ディレクトリ以下に Pipfile を作成します。ここに Vendoring 対象のパッケージを書きます。
プロジェクトで既に作成済みの Pipfile がある場合は、それをコピペすればよいでしょう。

[[source]]url="https://pypi.org/simple"verify_ssl=truename="pypi"[packages]click=">=6.0,<7"elasticsearch=">=6.0.0,<7"tabulate="*"[requires]python_version="3.6"

pipenv lock を実行して requirements.txt を生成します。
標準出力にはかれるのでリダイレクトしてファイルに受けましょう。

cdescher/vendorpipenv lock-r> requirements.txt

そして、vendor 以下にパッケージをダウンロードするためにpip install します。pip download では whl ファイルが落ちてくるのでダメです。このコマンドは今後のパッケージのアップデートにも必要になってくるので、シェルスクリプト化しておくといいですよ。（せっかく Pipenv を採用しているので、Pipenv のカスタムスクリプトとして用意してもいいですね！）

pipenv run pipinstall-t.-r requirements.txt-U

最後に、スクリプト内から普通にインポート出来るように vendor ディレクトリを sys.path に追加します。vendor ディレクトリのパスを取得するのに __file__ シンボルを使うと便利ですが、__file__ シンボルは厳密にはあったりなかったりするものなので、プロジェクトによっては注意してください。

importosimportsysfromescher.__version__import__version__PROJECT_ROOT=os.path.dirname(os.path.realpath(__file__))PROJECT_VENDOR=os.sep.join([PROJECT_ROOT,'vendor'])sys.path.insert(0,PROJECT_VENDOR)

Vendoring 導入に関して補足

プロジェクトルートの Pipfile は残しておいてもおかなくても良いですが、プロジェクトで使用するインタプリタのバージョンを指定するには必要になります。また、pip プロジェクトのように Vendoring するパッケージと Vendoring しないパッケージを区別したい場合もあるかもしれません。そういった場合には Vendoring しないパッケージをここで指定することで、Vendoring するパッケージと区別できます。

また、基本的に開発用のパッケージは Vendoring する必要ありません。開発用のパッケージというのは、pylint のようなコーディング補助用途のパッケージや、pytest のようなテスト用途のパッケージを指します。こういったパッケージもプロジェクトルートの Pipfile で指定しておいて、開発者のローカル環境で取得／管理してもらえばいいでしょう。

[[source]]url="https://pypi.org/simple"verify_ssl=truename="pypi"[dev-packages]isort="*"pylint="*"autopep8="*"rope="*"yapf="*"[requires]python_version="3.6"

Vendoring の注意点

Vendoring の導入は、他のパッケージから依存されない想定のパッケージに限定すべきです。具体的にいうと、Vendoring はアプリとして振る舞うパッケージには適しますが、ライブラリとして振る舞うパッケージには適しません。なぜかというと Vendoring には特有の問題があって、これは vendor ディレクトリがネストしてしまうことに起因します。

• How to handle nested "vendor" directories in Go packages? - Stack Overflow

ちなみに、vendor ディレクトリ以下を直接パス指定して import するアプローチもありますが、こちらもこちらで似たような問題が出るようです。

• Go言語のDependency/Vendoringの問題と今後．gbあるいはGo1.5 | SOTA

その結果、Go のパッケージ管理ツールでは prune という機能が用意されました。prune 機能は vendor ディレクトリがネストしないように、依存パッケージ内の vendor ディレクトリを消してしまう機能です。

• Vendor pruning · Issue #120 · golang/dep
• Commands - Glide Documentation（install コマンドの -v オプション）

もちろん、Vendoring がツールレベルで整備されていない Python では機械的な prune 処理はできませんので、ライブラリとして採用される想定のパッケージでは、そもそも Vendoring をしないようにするのが無難かと思います。

まとめ

Python でも Vendoring を導入できること、Vendoring を導入することで既存の問題が解決できることについて述べました。
ツールレベルでの Vendoring サポートがなかったり Vendoring 特有の問題もありますが、Vendoring を採用することで Python の可能性が広がるのでぜひぜひ試してみてください！