I think that the idea itself sounds grand. No doubt there'll be some implementation hurdles, but it all makes sense.<p>But:<p>> 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…<p>Seriously, the only things good about JSON (and it <i>is</i> 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.<p>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.
This is more or less a tool-supported version of what we do at work--I've posted about it a few times, to sneering response.<p>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.
Don't get too excited. This proposal is more a codification of the "easy" part of managing dependencies for top level/binary packages that much of the community already does.
This proposal does not (and isn't intended) to cover how dependencies work when vending libraries and does not address shared package and diamond shaped dependencies.<p>That's not to say having a standard for vendoring isn't a good thing.
Things seem extremely nice in go when you start out in go and see "go get", but then you'll quickly ram into not wanting the latest master, and then get extremely puzzled about how to do library dependencies.<p>I wish I saw some sort of consensus on library dependencies in that thread. Too much of our work build relies on setup scripts.
I thought this was a decent proposal:<p><a href="https://github.com/mattes/go/blob/fix-dependencies/fix-dependencies.md" rel="nofollow">https://github.com/mattes/go/blob/fix-dependencies/fix-depen...</a><p>Discussed here:<p><a href="https://www.reddit.com/r/golang/comments/2xeuu0/allow_revisions_in_import_path_like_go_get/" rel="nofollow">https://www.reddit.com/r/golang/comments/2xeuu0/allow_revisi...</a>
The issue of disappearing vendors can largely be solved using godep and distributing binaries, but I don't feel like any language I've used has an effective mechanism for coupling unit testing with dependency management.<p>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?
glide works really well for this: <a href="http://technosophos.com/2014/09/22/how-glide-solves-go-vendoring.html" rel="nofollow">http://technosophos.com/2014/09/22/how-glide-solves-go-vendo...</a>