
Code.google.com was shut down, Go packaging is broken - dz0ny
https://go-review.googlesource.com/#/c/18952
======
twblalock
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.

The Go maintainers have conflated _what_ a library is and _where_ a library
is. That's an important distinction that should not be glossed over like this.

~~~
voidlogic
I've been using Go professionally since 0.8 and in production since 1.0; this
is correct.

Since day one we have forked every (external) package dependency in production
code to our own github account and for all the constant complaining I hear, it
has been very little heartache for us.

This has worked great, we periodically update our forks from upstream, once or
twice a year need to fixup our code to match, run our unit tests an
integration tests, do a little manual testing and call it good.

~~~
nothrabannosir
Vendoring through tarball dumps of GOPATH I can understand, but how do you
deal with the dependencies of your dependencies when vendoring through
forking?

~~~
voidlogic
Of our 40 or so external dependencies (huge project), only a handful
themselves have dependencies we needed to also vendor. Its sounds painful, but
in practice it hasn't been. We actually stopped using godep, we were getting
no reward for the hassle and added complexity.

Unless there is a bug, or new feature we needed, we often just update this
stuff when we update the Go release we are using.

My thoughts; KISS until more complexity is _actually_ needed.

~~~
nothrabannosir
_> My thoughts; KISS until more complexity is actually needed._

Well, isn't that exactly what this artice is about…?

------
jacobr
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.

~~~
fortytw2
Do you foresee GitHub shutting down in the next 5 years? I certainly don't.

~~~
vortico
Actually perhaps. If the current team continues to own and run it, it'll be
around forever. But eventually they'll want to sell it, the team will change,
and its goals will become more feature-oriented for the sake of grabbing more
premium members. This will give it less value (due to the removal of
simplicity) to the average user, so its userbase will gradually shrink until a
few years later they pull the plug. It's happened to almost every web service
more than a decade old.

~~~
tcopeland
Remind me of this Slashdot comment about killing the goose that laid the
golden eggs:

[http://news.slashdot.org/comments.pl?sid=7754987&cid=5019893...](http://news.slashdot.org/comments.pl?sid=7754987&cid=50198935)

Perhaps GitHub will be able to resist "change for change's sake".

------
vruiz
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.

Also remember that while not very widely used, Go does provide support against
this problems via custom URLs and canonical import paths [0].

And most importantly, whatever your programming language, remember to vendor
your dependencies.

[0] [https://texlution.com/post/golang-canonical-import-
paths/](https://texlution.com/post/golang-canonical-import-paths/)

------
golergka
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?

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:

    
    
      build:
          GOPATH=$(shell pwd) go install main
    

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.

~~~
eternalban
My opinion: What they got right is what Rob e.g. concurrency, better C, etc.,
had figured out (so it was version n). Other stuff he apparently doesn't
understand at the same level (e.g. [type systems, versioning,] hard coding
repo locations in package imports <head smack>) ...

[edit]

~~~
golergka
Could you elaborate more about type systems? I don't have a definite opinion
about Go's type systems so far, and it surely has it quirks, but TBH, I like
the concepts. In particular, the complete separation of data types (structs)
and behaviour types (interfaces) is something that I've never actually seen
before.

~~~
eternalban
That horse has been beaten to death elsewhere. Go is [a] sweet language, don't
get me wrong, but it is a mixed bag of extreme brilliance ('select') & head-
scratching wtfs (OP).

Interfaces are hardly new. Go's novel take is the 'auto-morphism'[1] of types
that (happen) to implement the function set aggregated in an interface. And
this approach has its strengths and its weaknesses.

[1]: ok, I made that up.

------
4ad
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 _in general_ , which is false.

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 _test_ which didn't impact anything else; something
that people working _on_ Go have to deal with, not something _users of_ Go
have to deal with.

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.

~~~
lolc
Thanks for your clarifications.

------
csense
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.)

~~~
ProAm
Just host it yourself. People act like managing a server is akin to brain
surgery these days. The 'cloud' is great, but this is what you have to plan
for and deal with if you don't want to do it yourself.

------
petke
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.

Edit. What happens to the thousands of webpages that link to jquery or google
fonts on google.code. This must break lots of things ...

~~~
dspillett
To be fair they did give ten months notice so people had time to manage the
change, and what we are talking about here isn't "correct" use for that
service anyway (it was for source and issue management, not library hosting or
a more general CDN).

~~~
runholm
Doesn't help the fact that Google repeatedly shut down services that are in
use. It is getting harder and harder to use Google services in business
because it has become a liability.

~~~
hahainternet
"it" being "The idea they might shut down a free service with only 10 months
notice".

If your company relies on Google to this extent, and does not have the staff
to fix the issues inside 10 months then you need to reconsider your business
plan.

------
lukaslalinsky
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.

~~~
manojlds
Less impactful, but docker images have to be tagged with the docker registry
URL they will be pushed to.

~~~
lukaslalinsky
That's another thing I always disliked. I'd have preferred a configurable
prefix, or something like Git remotes.

------
donatj
'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.

------
CSDude
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.

~~~
mseepgood
> I have to change all the required import paths to my repo path

GO15VENDOREXPERIMENT=1 will be default behaviour in Go 1.6. So you don't have
to rewrite the import paths anymore.

> Or I have to provide it in vendor folder

What's wrong with that?

~~~
zimbatm
> What's wrong with that?

Vendoring external dependencies adds a lot of noise to your git history.
Especially with github's UI it's easy to miss an important change because of
skipping trough the vendor changes or getting the "too many changes to
display" message.

~~~
anonx
> Vendoring external dependencies adds a lot of noise to your git history.

This is my concern as well. Is it possible to use git submodules in vendor
directory? Looks like it is possible [1].

[1]:
[https://github.com/golang/go/issues/12573](https://github.com/golang/go/issues/12573)

------
lolc
"This change drops support for code.google.com and fixes test."

How was packaging broken?

~~~
dz0ny
Some apps/packages still use packages hosted on code.google.com. Basicly you
have to update dependency tree for packages that were hosted there. If you
vendor packages then you are not immediately affected but it still poses a
problem in long term.

------
Lethalman
How Nix solved the issue:

1\. Each go package has an attribute name in nix, like anything else, that is
not tied to its url.

2\. Each go package has an url where to fetch the source from, which is not
the import path to use the package.

3\. Each go package has a number of old import url aliases (e.g.
"code.google.com/...")

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.

So the problem is solved at our packaging level.

This is not to say it's the best solution, but certainly a good alternative
solution.

------
akerro
Uff just in time I moved some projects I relay on from CG to Gitlab...
developers didn't bother.

------
msie
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"?

------
tmaly
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.

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.

------
eternalban
Someone needs to let the Gophers know about this little concept known as
'indirection'.

------
0xFFC
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.

They want just shove the internet to your throat. With all of their product.

