Experimental Dependency Vendoring in Go 1.5

Re:Experimental Dependency Vendoring in Go 1.5 by enneff on Thursday June 11, 2015 @03:21PM (#9701721)

With this scheme libraries can vendor their dependencies, if necessary.

[ Parent | on HN ]

Re:Experimental Dependency Vendoring in Go 1.5 by drewolson on Thursday June 11, 2015 @03:24PM (#9701738)

Can you reference the part of the proposal that states this? I'm reading the following points:

> $GOPATH/src/foo will be imported as foo by non-main package $GOPATH/src/mypkg/p.

> $GOPATH/src/mypkg/external/foo will be imported as foo by a non-main package p anywhere, when p is being built as a dependency of command $GOPATH/src/mypkg/c.

It seems to me this is saying that libraries will use external packages only when built as a dependency of a main package. Again, this means library authors are out of luck.

[ Parent | on HN ]

Re:Experimental Dependency Vendoring in Go 1.5 by jooon on Thursday June 11, 2015 @04:40PM (#9702248)

There are two proposals.

You seem to refer to the Google doc proposal that was linked to in the first message of the mailing list thread several months ago.

The link on hackernews points to an answer by Google that was written just a few hours ago that instead "propose" the following:

> If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.

[ Parent | on HN ]

Re:Experimental Dependency Vendoring in Go 1.5 by drewolson on Thursday June 11, 2015 @05:03PM (#9702422)

Ah, thanks.

[ Parent | on HN ]

Re:Experimental Dependency Vendoring in Go 1.5 by groks on Friday June 12, 2015 @07:45AM (#9705260)

You're pushing the Go ecosystem in this direction:

    https://spot.livejournal.com/312320.html

[ Parent | on HN ]