Hacker News Reader

Comment by nulltype | Hacker News Reader

I think it does support multiple versions of a package, as long as the package supports multiple versions of a package. 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.

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.

View on HN

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

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.

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.

Reply on news.ycombinator.com