I think the only realistic solution to this is to vendor your go dependencies. If Github ever changes its URL schema, a whole bunch of stuff is going to break.<p>The Go maintainers have conflated <i>what</i> a library is and <i>where</i> a library is. That's an important distinction that should not be glossed over like this.
It will be great fun when Github is shut down. Many npm packages, jspm, and more are using hard coded links to repositories or even paths in repositories.
Please note that the linked URL is just a commit to remove support from code.google.com in go get, and add a warning to users trying to go get from it.<p>Also remember that while not very widely used, Go does provide support against this problems via custom URLs and canonical import paths [0].<p>And most importantly, whatever your programming language, remember to vendor your dependencies.<p>[0] <a href="https://texlution.com/post/golang-canonical-import-paths/" rel="nofollow">https://texlution.com/post/golang-canonical-import-paths/</a>
I just got into Go, and I'm a fan a lot of language design decisions. But a lot of configuration leaves me wondering: is it me who doesn't understand something, or did the same folks who designed such a good language actually screwed up configuration stuff?<p>No way to specify a version of library or language I'm working with is already a little bit annoying, although I haven't actually discovered problems because of it. But the $GOPATH just drives me nuts: why the hell would the language infrastructure work out of assumption that all my projects that are based on a single language are contained in a single folder? On the contrary, I often have projects that include several different languages and frameworks in them, and I'm usually keeping client and server in the same repo. Language is a part of a project, not the other way around. I ended up with this hackery in my server Makefile:<p><pre><code> build:
GOPATH=$(shell pwd) go install main
</code></pre>
Overall, just as Go itself is transparent and simple, it's `import` statement and build infrastructure is not. "Convention over configuration" may be a good approach for simple web apps, but when this convention just doesn't fit your workflow, it brings more bad than good.
I've flagged this editorialized title (Code.google.com was shut down, Go packaging is broken). Apart from being against the rules, it's intentionally misleading. It gives the false impression that Google Code shutting down somehow caused go get functionality to fail <i>in general</i>, which is false.<p>Go get works as always; of course you can't go get go packages on Google Code, because Google Code doesn't exist anymore! The link just points to a change that fixes some trivial Go <i>test</i> which didn't impact anything else; something that people working <i>on</i> Go have to deal with, not something <i>users of</i> Go have to deal with.<p>As for the news about Google Code itself, that was announced almost an year ago. The Go project itself migrated to git well before that, and of course, every Go package that's maintained also migrated off Google Code in the meantime. This is (misleading) non-news.
The "website going out of business destroyed my content" problem is one that needs to be addressed. One promising idea is content-addressable storage, like IPFS-hosted repos -- anyone can self-host at a stable URL. (I don't know if IPFS has a good solution yet to the problem branches solve in git, namely having a named, auto-advancing pointer to the content address of the latest version.)
Google shuts down yet another service developers rely on. Its getting quite a bad track record. Trust is not so easily rebuilt. I think more developers will avoid depending on google services in the future if they have another choice.<p>Edit.
What happens to the thousands of webpages that link to jquery or google fonts on google.code. This must break lots of things ...
I never really understood why would they map package names to the sites that host the sources. It was obvious something like this was going to happen and it's happening on smaller scale all the time. Projects move.
'go get' is a highly useful bag of cats. The fact that code.google.com needed to be hard coded rubs me in such the wrong way for what should be a generalized tool. I wish instead of magic self resolving paths, it just took git repo ssh/http paths.
I hate go packaging. I want to fork a package for my private purposes, maintain it in my hosted repo or somewhere private, but no, I have to change all the required import paths to my repo path. Or I have to provide it in vendor folder, or have custom gopath folders, but then go get does not work, I have to git clone and put it in some weird old repo's path. You could use relative paths, or package names but no, you had to use site urls so you could make it harder for anyone that does not work open source or private. I have not found a better solution for forking a repo and working it on my own besides vendor folder solution.
How Nix solved the issue:<p>1. Each go package has an attribute name in nix, like anything else, that is not tied to its url.<p>2. Each go package has an url where to fetch the source from, which is not the import path to use the package.<p>3. Each go package has a number of old import url aliases (e.g. "code.google.com/...")<p>4. Whenever a package X depends on Y with an old import url, then X is rewritten to use the new url path of Y using govers.<p>So the problem is solved at our packaging level.<p>This is not to say it's the best solution, but certainly a good alternative solution.
Isn't any packaging system reliant on a server and ultimately fragile if you don't vendor? I don't want to see an overengineered packaging system. Go is open source, has anyone looked at improving "go get"?
I cannot blame Google, they ditched the Reader and various other free services. the Code service may not have been a core thing for the company.<p>Github on the other hand does have a core focus on hosting code. I would expect them to be in this business as long as it is profitable for them.
This is exactly why I am trying to avoid Google's product as much as possible and suggest people avoid them as much as possible.<p>They want just shove the internet to your throat. With all of their product.