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での議論
78- p4bl0
確かにそうだが、使っているドメイン名には注意が必要だ。VeriSignが一方的にあなたのドメイン名を何千もの他のドメインと一緒に削除することを決めるかもしれず[1]、振り出しに戻ってしまう…
- thih9
> 私の意見では、Goを使っている商用ソフトウェア開発チームは、内部ライブラリやパッケージの名前空間化のためにカスタムドメインを使うべきです。
上の文から「Go」を削除したい。つまり、同じことが他のスタックにも当てはまると思う。
コードコメント内でGitHubのドメインリンクを使うことさえ、長期的には問題になる。つまり、移行が起こり、それらのリンクがどこも指さなくなるような場合だ。
- serbuvlad
> つまり、GitのホスティングをGitLabに移したら、コードを変更しなければならない！
皮肉を言うつもりはないが、非常に稀なイベントの後にsed s///gを実行することが、深刻な問題に値するとは思えない。
確かに、解決策がとても単純であることを考えると、それは良い推奨事項だが、それでも…
- dewey
> つまり、GitのホスティングをGitLabに移したら、コードを変更しなければならない！
go.modファイルに「replace github.com/example/example => gitlab.com/example/example」と書くだけで、すべてが動作し続ける。それは、本当に重要でないことに対する非常に早すぎる最適化のように思える。
- 0xCMP
これは素晴らしいし、ドメインが登録され維持されることを確実にしようとするどんな企業や個人にとっても、非常に理にかなっていると思う。壊滅的ではあるだろうが、GitHubが消滅したり、そこから離れることを要求するようなポリシーを変更したりできない理由はない。Goの仕組みにより、これらのパッケージ名をGitHubに結びつけてコミットすることは、単にプル元の場所である以上にずっと重みがある。
一つ心配だったのは、Nginx設定の例で301を返すことだ。クライアントがリダイレクトされるURLを変更したい場合、古いURL設定を訪れたブラウザは、古い設定のリダイレクトURLに強制的に飛ばされることになる。`go ...`や`curl`では問題ないが、Chrome/Firefoxはその301を永久にキャッシュし、意図したリダイレクトを壊してしまう。実際にこれが問題になるかどうかはわからないが。