> The problem is if a package registers some global name, and another copy of the package also registers the same global name, that could cause an error.
This shouldn't cause an error, because packages can only register globals within their own namespace. You just end up with two copies of it, with different types.
That would be nice, but that is not true in Go. You can register with a function like this one: http://golang.org/pkg/database/sql/#Register (mentioned in the article) and run it in your init() function or any similar function that a client calls.
That will collide with any other package that also uses that registration function for the same value of 'name'.
Right, when you leak handles to package objects externally, all bets are off.
A separate but more important issue is that you still have two copies of any global state managed by/contained within that library in memory.
That is basically guaranteed to lead to bugs.
One that definitely happens is if, for instance, a library returns datastore.ErrNoSuchEntity, but vendored the "datastore" package. If you have your own version of "datastore" then you do "err == datastore.ErrNoSuchEntity" and it's false, because there are two copies of ErrNoSuchEntity in memory.
This seems pretty solvable though. If you vendor a package, you need to make sure you don't do this. If we do gb-style everyone vendors stuff themselves (not in libraries), then it's not an issue.
The name conflict is a compiler error message, not anything to do with vendoring.
Having a package.json file is a separate issue, but there is a proposal for that here: https://groups.google.com/forum/#!msg/golang-dev/nMWoEAG55v8...
Having a file like that doesn't solve the vendoring issues though. This new vendoring scheme seems almost identical to NPM's node_modules.