Don't Couple Your Go Code to GitHub
Go's convention of using the fetch location as the import path ties your code to a specific git host. Iain Cambridge explains how this coupling forces some companies to pay for multiple hosting services simultaneously, and shows how custom domains like go.iain.rocks solve the problem with a simple Nginx and HTML setup.
So you literally end up with your code coupled to GitHub. Which sounds completely nuts, but it’s something that is pretty much defacto in the Go community.
- p4bl0
True, but beware of the domain name you're using. Because VeriSign may unilaterally decide to delete your domain name along with thousands of others [1] and you're back to square one…
- thih9
> In my opinion, every commerical software development team using Go should be using custom domains for namespacing their internal libraries and packages.
I’d remove “go” from the above, i.e. I think same applies to other stacks.
Even using GitHub domain links in code comments gets problematic long term. Ie when a migration happens and those links start pointing nowhere.
- serbuvlad
> That is, if you move your git hosting to GitLab then you have to change your code!
Not to be cynical about this but I fail to see how running sed s///g after a very rare event qualifies as a serious problem.
Now, sure, given that the solution is so simple, it's a nice recommendation, but still...
- dewey
> That is, if you move your git hosting to GitLab then you have to change your code!
You can also just use "replace github.com/example/example => gitlab.com/example/example" in your go.mod file and everything will keep working. That seems like a very pre-mature optimization for something that doesn't really matter.
- 0xCMP
This is great and I think for any company/individual who is going to ensure their domain is registered and maintained this makes a lot of sense. It would be catastrophic, but there is no reason Github couldn't disappear or otherwise change some policies that require moving away from it. The way Go works makes committing these package names tied to Github so much more weighty than simply the place you pull from.
The one thing that I was worried about was returning 301 in the example Nginx config. If you ever wanted to change the url that clients are redirected to then any browsers that visited the old url config would be forced to go to the old config's redirect url. For `go ...` and `curl` it wouldn't matter, but Chrome/Firefox will cache that 301 permanently and break the intended redirect. Not sure if this is really an issue in practice though.