依存関係の取得はVCSから直接行うべき理由

依存関係をパッケージマネージャや外部レポジトリ経由ではなく、バージョン管理システム（VCS）から直接取得・管理すべきであるという技術的な提案です。これにより、ビルドの再現性を高め、外部ソースの消失や不意の変更によるトラブルを未然に防ぐことが可能になります。

パッケージって、元のリポジトリ内にある時と公開された後では中身が別物になっていることがよくあるよね。トランスパイル、ビルド、コンパイル、パッケージング、何と呼ぶにせよ、人気のプロジェクトのほとんどは、使える状態になる前に何らかの形で動的なコード実行を必要とするものだしね。Gitを中央集権的なレジストリに代わる現実的な選択肢にしたかったという気持ちはわかるけど、ここ数年の状況を見ると、インストール中に任意のコマンドを実行させるというのは、大規模な運用をするにはリスクが高すぎるっていうのがはっきりしたね。

完璧な解決策なんてないよ。個別のレジストリに公開しておけば、Gitリポジトリのリネームや移行、削除があっても生き残れる。Gitホストに依存しすぎるのも考えものだしね。VCSとレジストリを分ければそれぞれ異なる機能セットを提供できるし、複数のレジストリに同時公開することを止める理由もないわけだし。

他の人たちはleft-padの騒動を忘れるほど若いのかもしれないけど、あの時にみんな学んだはずだよ。専用の依存関係リポジトリの最大の利点の一つは、依存関係の「アンパブリッシュ（公開取り消し）」を拒否できることなんだ。Githubや他の人気のホスティングサービスがそんな保証をしてくれるわけじゃないからね。

オンラインであり続けることを前提に、いろんなVCSに依存するのも果たして良いアプローチなのかどうか。Goの場合はPure Goのエコシステムがかなり広いから、ソースコードベースのライブラリ配布には向いてるよね。インタプリタ言語だと、パフォーマンスが重要な処理は結局別のコンパイル言語にオフロードされがちだから、すべてを動かすためにいくつものツールチェーンが必要になる。静的にリンクされたバイナリライブラリは、便利な抽象化レイヤーだよ。

みんなGoの解決策がなぜこれほど優れているのかを見落として返信している気がするな。もっと注目されるべきだよ。多くの場合、分散化に伴う苦痛を避けようとすると本末転倒になるし、分散化には難しい課題が多いから、結局中央集権的な権威やコンポーネントに頼る方が楽なのはわかる。Goをインストールすると、基本的にはモジュールプロキシから取得しようとして、失敗したらフォールバックするようになっている。でも、Goが面白くて特別なのは、それを何の影響もなくオフにできる点だ。Gitホストが生きている限り、プロキシなしでもGoは普通に使える。NixのビルドはデフォルトでGoに対してそう動いているはずだから、依存関係はたいていオンラインで確保できるはず。つまり、プロキシ方式と分散方式が互いに完全に冗長性を保ちつつ、分散型のVCSホストをソース・オブ・トゥルース（信頼できる唯一の情報源）として維持できるんだ。さらにGoにはsumdbがあって、イミュータビリティ（不変性）を保証できるから、特定のパッケージを取得したときに、そのタグ名が唯一無二のソースコードに対応していると確信できる。これも必須じゃないし、仮になくてもローカルキャッシュやgo.sumファイルでチェックできる恩恵はある。こうした機能が分離されているのが素晴らしいのは、サードパーティのプロキシやsumdbを個別に選んだり、あるいはsumdbだけ使ってプロキシは使わなかったりといった柔軟な運用ができるからだ。単一の組織に頼り切ることなく、中央集権のメリットも享受できる。こういうシステムは稀だよ。多くのシステムは良いとこ取りをしようとして失敗しがちだけど、Goのアプローチは実際に機能しているし、もっと注目に値する。

これまで何度かVCSが汚染されたことがあるから、その方向で進むなら周囲のセキュリティを大幅に強化しないと無理だよね！

これが正しい解決策なのかは2つの理由で疑問があるな。まず、パッケージ作成者が使っているVCSプロバイダーを、言語のモジュールインフラの一部として組み込むことに抵抗がある。次に、バージョン管理下のすべてのファイルがtarballに含まれるべきとは限らないし、逆にtarballの中にあるファイルすべてがバージョン管理されている必要もない。とはいえ、依存関係の変更を追跡する簡単な方法が必要だという点には納得だよ。一つのアプローチとしては、パッケージの公開を、通常tarballに含まれるファイルをコミュニティ管理のVCSにインポートする作業に集約させるとかかな。