> 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.
I'm confused by the article, and this comment, treating these URLs as difficult to replace.
Why can't you just search-and-replace? Presumably all of them refer to "GitHub.com" and not much else code will, so I'd think this was an exceptionally easy case.
Even easier for comments, since them being obsolete for a few hours during a migration doesn't exactly break anything.
Even easier than that, you can use the 'replace' statement in your go mod to change where the Go build system will try to pull the dependencies from; you can point to a folder on disk or to another forge, and if you want total control you can indirect everything to your own artifact cache via GOPROXY (which can be something as simple as a static folder of source code).
The "module name is network path" is a convenient convention but not at all some "limitation" of the tooling.
com.sun is an identifier, nothing more. No tooling sees com.sun and assumes, "oh that means I can make an HTTP request to the IP address which sun.com resolves to".
In Go, the package identifiers are literally URLs. Go's own tooling assumes that it can make an HTTP request to the URL and that the response will be HTML with particular tags which Go's tooling will parse and use to resolve a git repository which can be 'git clone'd. Leaving them as-is when you abandon the infrastructure they reference literally means leaving dead links in your source code.
That's just the default, which you can easily override if you need to. IMO there is nothing wrong with treating Go package names as arbitrary identifiers like com.sun.* If you're spending a lot of time updating imports because the underlying repo has moved from its original URL, then just don't do that. It's unnecessary.
thih9 · · focus · HN ↗
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.
handoflixue · · focus · HN ↗
Why can't you just search-and-replace? Presumably all of them refer to "GitHub.com" and not much else code will, so I'd think this was an exceptionally easy case.
Even easier for comments, since them being obsolete for a few hours during a migration doesn't exactly break anything.
lelandbatey · · focus · HN ↗
The "module name is network path" is a convenient convention but not at all some "limitation" of the tooling.
mort96 · · focus · HN ↗
someonebaggy · · focus · HN ↗
mort96 · · focus · HN ↗
In Go, the package identifiers are literally URLs. Go's own tooling assumes that it can make an HTTP request to the URL and that the response will be HTML with particular tags which Go's tooling will parse and use to resolve a git repository which can be 'git clone'd. Leaving them as-is when you abandon the infrastructure they reference literally means leaving dead links in your source code.
foldr · · focus · HN ↗
mort96 · · focus · HN ↗
foldr · · focus · HN ↗
mort96 · · focus · HN ↗
someonebaggy · · focus · HN ↗