vendoring (依存のリポジトリ内取り込み)

外部依存のソースを自リポに取り込むこと。build 再現性を上げるが drift と二重管理の対価がある

要点 #

vendor する = 外部依存 (ライブラリ / パッケージ) のソースコードを自分のリポジトリまたはビルドツリーに取り込み、外部から取得せずに build/run できる状態にすること。名詞 "vendor" (供給者) から派生した動詞。

ビルド再現性: 外部リポが消滅・tag が動く・URL 変更で CI が壊れなくなる
依存解決の単純化: package manager (apt/rosdep/pip) に未登録の内部/未公開ライブラリを build system に持ち込める
オフラインビルド: Docker image に事前焼き込み可能
patch を先行適用: upstream の PR merge を待たずに自分側の修正版を使える

ROS 2 コミュニティの慣習で、外部の非-ament ライブラリを ament の依存グラフに乗せる薄いラッパーパッケージが <name>_vendor の命名で存在する。実例:

中身は薄い CMake で:

ExternalProject_Add() で upstream の tag/commit から source を fetch
ament の build tree 内で configure + make + install
<name>_vendorConfig.cmake を export、下流 package が find_package(<Name>) で見つけられる形に整える

これで下流の ROS 2 package は、外部ライブラリが <name>_vendor 経由で来ていることを意識せずに使える。

vendoring 以外で外部依存を扱う方法:

package manager にリリース: rosdep + apt / pip / cargo / go mod で公式解決。依存追跡はきれいだが release パイプラインが要る
vcs import (ROS 2 の場合): .repos ファイルに列挙、vcs import でワークスペースに clone。CI 内で source ビルドできる。upstream 追随が容易だが clone 時間が毎回かかる (cache でカバー可)
git submodule: submodule として参照。commit ピン留めできるが submodule 特有のフットガンあり (git clone --recursive 忘れ等)

状況	推奨
upstream が安定していて頻繁に触らない	vendor
頻繁に upstream を追う (fork して patch を当てながら開発)	vcs import + patch commit
社内で ownership を持つライブラリで、他 project も使う	社内 apt / registry に release
一度きりの小さな依存	vendor (drift も最小限)

vendor は最短で問題を消せるが、二重管理のコストが継続する。「今回だけ動けばいい」を続けると vendor したライブラリが 5 個増える。upstream にリリースパイプラインを引けるなら、その方が中長期の負債は小さい。

最終更新: 2026年9月16日