Code.google.com was shut down, Go packaging is broken
go-review.googlesource.com
go-review.googlesource.com
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.
repositories { ... }
dependencies { compile "group:name:version" }
On the positive side, some of the complexity comes through enforcing some standards about what packages go into central - in particular you must have a properly declared license, developer contact information, and GPG sign your releases. Which are things other language ecosystems would do well to enforce.
If by "standard" you meant "default", like Maven Central is the default in Maven, here I have some news for you as well. Bintray is the default in Mac OS' Homebrew, Android Studio, Groovy's @Grab, and first class citizen in Gradle, Ivy and SBT.
I think this depends on whether GitHub treats URLs as just URLs, or more generally as URIs. Based on their documentation [0], they refer to them as URIs, which means they are intended to represent both Location and Identity [1]. The domain represents the "where", the repository path is the "what".
They should be able to change their URL schema relatively easily, by including the appropriate redirects - a mapping from the old schema to the new. Which is exactly the strategy they discuss in the HTTP Redirects section.
(edit) Formatting
[0] : https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
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.
I wish the go get tool would download to the vendor folder when using GO15VENDOREXPERIMENT
I'm not the parent but your question is completely valid -- trying to get dependencies of dependencies sends us down a very deep rabbit hole.
This is usually where dynamic linking and shrinkwrapping[1]/vendoring[2] start entering serious discussions.
[1] http://blog.goguardian.com/nerds/shrinkwrap-not-just-for-mur...
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.
Well, isn't that exactly what this artice is about…?
I can kind of understand the Go devs' POV which is that basically at Google all source code vendored under one giant tree, but that's just not how not-Google companies operate.
Rust is looking really attractive to me lately, as soon as I figure out lifetimes and the borrow checker completely....
This is something which is seen over and over again. Its not that loved active services and sites get turned off, it's that the userbase moves somewhere else first.
http://news.slashdot.org/comments.pl?sid=7754987&cid=5019893...
Perhaps GitHub will be able to resist "change for change's sake".
As for the rest of us, you can't possibly see or guess the future that will affect that business. Maybe they'll get sued out of existence by then? Maybe the owners will run it into the ground? We hope it will continue to exist, but we can't possibly know until then.
Exactly, a bad player could do much more damage than simply turn the services off. A lot of the time there is no verification for the downloaded code. It's just being run.
its supposedly being handled by either ssh or libcurl
or are you talking about these frontends like source tree, smartgit, ... ?
I cannot even begin to imagine how it would react to it being MITM'd.
Doesn't the fact that GitHub makes the enterprise pay for usage make it more likely that GitHub will be around longer than Google Code?
Honestly, if GitHub can stick around for another 10-15 years that would be ideal. By that time I should either be out of the industry or off to another company that uses something other than GitHub.
Plenty of companies that charge for things have gone out of business.
No. Seriously. It just makes it more likely they screw up private companies as well on the way out!
We need a decentralized github.
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/
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
[edit]
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.
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.
Edit. What happens to the thousands of webpages that link to jquery or google fonts on google.code. This must break lots of things ...
If they were, I have little sympathy. It's entirely inappropriate to co-opt a repository hosting service as a CDN.
AFAIK, Google uses code to host internal projects as well as open source projects.
Apparently some users were spamming and/or hosting illegal content for download. Instead of spending resources fixing what is essentially a free service to the public, they just shut it down and converted all repos to read-only mode.
At this point, I pretty much assume that any service that Google offers for free sans advertising exists to attract free beta testers. Eventually, it'll be converted to either a paid service or internal-only use.
Source: lots of time wasted migrating projects to GitHub.
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.
For this reason, you have wrappers like http://gopkg.in/ , which permit some freedom in the form of git tags.
(I fully agree that Go packaging is very sensitive to API changes and incidents like sites disappearing altogether.)
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?
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.
This is my concern as well. Is it possible to use git submodules in vendor directory? Looks like it is possible [1].
This course has fourth year undergrads and masters' students. Most are familiar with some languages but aren't too used to production code practices (basically, one of the target audiences for Go -- be simple so that everyone can ramp up). Some have said that they preferred submodule deps or pythonesque easy-to-copy and easy-to-play-with import statements (and pip install) over this.
There is the valid argument to be made that any model for publishing your package is going to be tougher than a simple github URL, but it doesn't have to be much worse. With Rust, for example, you need to run `cargo login` once (which will direct you to a page where you can make an account if you need to) to set up, and then `cargo publish`. Pretty easy to learn.
I like a lot of things about Go, including it's simplicity. I wish I had more time to write Go, because it's a fun language to work with. But $GOPATH and URL-packaging are not amongst the Go features which I like.
How was packaging broken?
code.google.com/foo/bar package is the physical address were go get command will fetch the package. If that address is broken then the code is broken.
Go doesn't have a package manager either. Go Get is certainly not a package manager.
So when you use a third party package you have to fork it somewhere. The problem is that 2 libraries with the same exact code are different packages if their address is different. So sometimes it becomes a bit insane to work with third party libraries if people start forking them for safety.
I consider this whole package url thing as a design mistake. But most of the Go community sees no problem with it.
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.
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.
They want just shove the internet to your throat. With all of their product.