> godep already uses JSON, as do Go tools themselves (e.g. “go list -json fmt”), so we’ll probably want something like godep’s JSON format…
Seriously, the only things good about JSON (and it is good) are that it's so widely supported and that it has a clean representation of maps/dicts/hashes/whatever-you-call-them. Take a look at the two lines of text config in the article, vice the twelve lines of JSON.
What's wrong with nice, clean formats line text lines, s-expressions, even .ini? JSON is better than XML, but that's damning with faint praise.
Sure, JSON might be a bit more verbose for the "Hello World" scenario, but in mid-range sizes, it's still pretty clear (compared to the verbosity of XML) and doesn't require custom tooling to deal with (like ini files).
There are some formats with less braces (replaced with indents and with less key stuff) that are (I think) isomorphic to JSON that would be nicer to use for everyone involved, though.
The config file thing would hopefully be nice and small/simple so it's not a hassle to use. I think their '“rsc.io/x86/x86asm” with revision af2970a7819d' format would be more pleasant than JSON, but if they need more detail than just a repo path and a revision, JSON may be the way to go.
That's not to say having a standard for vendoring isn't a good thing.
I wish I saw some sort of consensus on library dependencies in that thread. Too much of our work build relies on setup scripts.
Additionally, it completely breaks if you depend on a package which depends on a specific version of another package. You are stuck using that version or forking your dependency to update the dep.
Wouldn't it make sense to be able to test your code in advance of updating a dependency to see the how's and why's of its failures?
Godep isn't "canon". There lies the problem. There should be no need for godep,the library dependecy issue should be solved once and for all by the go team so everybody uses the same library dependency manager. Vendoring dependencies solves nothing. Should I bundle these dependencies If I put my libs on github? and what if a dep has a bug? how do I know what version was used if I want to fix the lib myself? All that stuff stinks. I like Go but these are serious issues that will backfire, because other plateforms have been there and done that...
Java uses Maven or Gradle: third party
Python uses pip: third party
Ruby uses gems: third party
Node.js uses npm: third party
I'm sure I'm missing some, but this seems to be the norm. Go just hasn't been around long enough for a single third-party solution to become the de facto standard.
* Thinks that dependency management of third party libraries is an important problem in their project.
* Demands that there be one centralized repo and method for that. No alternatives!
Maybe it shows that I am a C fan, but I kind of skew on the opposite of this spectrum. Really the most important part of your project is how you import a library? Really? Even out of chaos, like a language with no native support for it, it's a small chore and you get over it quickly. But I am not one of the types that agonizes over it, as I guess go people are.
Rust + Cargo.
FWIW pip is now bundled with Python unless specifically unbundled (e.g. by linux distros)
But this requires source control systems that can store the files for many projects at a time. (See today's other discussion about git.) 
Since there's no real difference, it doesn't really matter if you check in deps or have specific versions in a config file, either solution solves the underlying problem of having non-precise dependencies (i.e. just a github repo, or a version selector like >= 2.6)
alias go='GOPATH=`pwd`:$GOPATH go'