GoコードをGitHubに結合させるな
Don't couple your Go code to GitHub
Goはインポートパスにコードの取得先を含めるため、多くの開発者がGitHubなどのホスティングURLをそのまま使っている。しかし、これではホスティング事業者を変更するたびにコードを書き換える必要が生じ、実際にGitLab、GitHub、Azure DevOpsを同時に使い続ける企業もあった。筆者はgo.iain.rocksのようなカスタムドメインを使い、Nginxとgo-importメタタグでリダイレクトする設定を公開している。
もしGitホスティングをGitLabに移行したら、コードを変更しなければならない！そうでなければ、古いバージョンを取得し続けることになる。
HNでの議論
174- p4bl0
確かにそうだが、使っているドメイン名には注意が必要だ。なぜならVeriSignが一方的にあなたのドメイン名を何千もの他のドメインと一緒に削除すると決めるかもしれず[1]、振り出しに戻ってしまうからだ…
- thih9
> 私の意見では、Goを使っている商用ソフトウェア開発チームは、内部ライブラリやパッケージの名前空間としてカスタムドメインを使うべきです。
上記から「Go」を外したい。つまり、同じことが他のスタックにも当てはまると思う。
コードコメントにGitHubのドメインリンクを使うことさえ、長期的には問題になる。たとえば、移行が起きてそれらのリンクがどこも指さなくなったときなど。
- dewey
> つまり、gitホスティングをGitLabに移したら、コードを変更しなければならないのですね！
go.modファイルに「replace github.com/example/example => gitlab.com/example/example」と書けば、すべてが動き続けます。それは実際には重要でないことに対する、あまりにも早すぎる最適化のように思えます。
- nirui
GitHubのURLは少なくとも信頼できる識別子ですが、あなたのカスタムドメインはそうではなく、システムが慣れ親しんでいることを考えると、おそらくこれからもそうならないでしょう。ドメインはブランディングのためのもので、識別のためのものではありません。
もちろん、.onionのように識別子が組み込まれた特別なドメインは別です。.onionはそのように（暗号鍵で）生成されるため、ドメインが維持されなくなった後でも、他の誰かが簡単に制御を取得することはできません。
どうしてもGitHubを使いたくないなら、代替案として、go.modの`replace`ディレクティブと組み合わせて、.internalサフィックス（例：yourproject.internal/project）を使うだけです。ただし、それにはユーザーが手動でパッケージをダウンロード/インストールし、自分のgo.modを編集する必要があります。
- SenHeng
GitHubはほぼ永遠です。カスタムドメインは請求を止めれば消えてしまいます。オープンソース開発者なら、GitHubが消えるよりもその可能性の方が高いでしょう。
いつの日か、私たちは皆、依存関係のベンダリングに戻るのです。
- imhoguy
ドメインよりも、元の場所/作者/プロジェクトをより適切に扱う方法が必要だと思う。そのような「Go」プロキシはどれも、また別の単一障害点（SPOF）に過ぎない。
私たちはIPNS（IPFSのName Server部分）や何らかの分散型台帳に傾くべきだ。
- st3fan
企業が倒産してドメインが宙に浮くときには素晴らしい。次にそれを手に入れた者が、他の人が新たに依存するソースコードを引き継ぐ。これは他のエコシステムでも何度も見てきた。非常に悪い状況だ。
パッケージを自分のドメインの下に移すのは悪いアドバイスだ。あなたはMicrosoftのようにドメインの支払いを続けるほど優れることは決してない。人生に保証はないが、一つだけ保証できるのは、あなたが倒産するとき、そのドメインのことは最後にしか考えないということだ。
- 0xCMP
これは素晴らしいし、ドメインが登録され維持されることを確実にするどんな企業や個人にとっても、非常に理にかなっていると思う。GitHubが消えたり、GitHubから離れることを要求するようなポリシー変更があったりしない理由はないので、それは壊滅的だろう。Goの仕組みのせいで、これらのパッケージ名をGitHubに結びつけることは、単に取得元である以上にずっと重みがある。
一つ心配だったのは、Nginx設定の例で301を返していることだ。クライアントがリダイレクトされるURLを変更したいと思ったら、古いURL設定を訪れたブラウザは、古い設定のリダイレクトURLに強制的に行かされることになる。`go ...`や`curl`では問題にならないが、Chrome/Firefoxはその301を永久にキャッシュし、意図したリダイレクトを壊してしまう。実際にこれが本当に問題になるかはわからないが。