You don't have to vendor anything from your own repo, but you do have to vendor everything from outside your repo. (To be precise, the distinction is between inside and outside the directory containing the vendor directory.)
Aside from that, make sure that the dependency in question is being imported using the same import path by all the packages that need it. Not doing this is probably the most common cause of having multiple copies of a package linked in to your binary. On Tue, Jul 5, 2016 at 8:29 AM Sam Whited <s...@samwhited.com> wrote: > On Tue, Jul 5, 2016 at 10:17 AM, Konstantin Khomoutov > <flatw...@users.sourceforge.net> wrote: > > AFAIK, vendoring explicitly implements an all-or-nothing approach: > > you're supposed to resolve transitive dependencies yourself, and vendor > > them all. > > That's my understanding too, but it seems foolish to vendor a version > of a library that's in the same repo (eg. using the "root of the repo > is the library, and a cmd/ directory has a few commands are thin > wrappers around the library" project structure that's so common). > Since keeping up to date with the library that actually implements the > commands is part of the contract, vendoring it seems like a bad idea. > > —Sam > > > > -- > Sam Whited > pub 4096R/54083AE104EA7AD3 > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
