Comment by roskilli | Hacker News Reader

Comment by roskilli | Hacker News Reader

Parent Full thread

> Multiple versions of the same library will cause problems ... This is a limitation of ... but probably also a sane one

> Another issue (hat tip to onetruekarl) comes up when 2 vendored dependencies also vendor their own copies of another depencency with the same name ...

So I still don't see why people are content with having a vendoring solution that doesn't support multiple versions of the same package and strict ASCII name conflicts. I understand this is an experiment but it begs the question why it doesn't want to at least eventually bite off doing powerful things (it seems to handwave the hard problems with a future spec that kind might solve it - seemingly something probably orthogonal to this experiment).

I have really enjoyed what NPM did with a simple package.json file and enabling recursive dependencies. It seems like if go were to add a simple file that maps package name to package URL with a decent support for different URL protocols you could build the same recursive dependency graph and depend on multiple versions of the same package and also different packages with the same name.

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.

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

> It seems like if go were to add a simple file that maps package name to package URL with a decent support for different URL protocols you could build the same recursive dependency graph and depend on multiple versions of the same package and also different packages with the same name.

I think you could easily build something like that on-top of 1.5's vendoring.

Reply on news.ycombinator.com