I’m trying to write an independent client for some of our Juju API’s, to be able to poke at some of them/load test them without having to set up real agents.
However, I just ran into this issue trying to write a custom caller to github.com/juju/juju/api/Open()
$ go build leaseclaimer.go
# command-line-arguments
./leaseclaimer.go:163:3: cannot use modelTag (type "gopkg.in/juju/names.v2".ModelTag) as type "github.com/juju/juju/vendor/gopkg.in/juju/names.v2".ModelTag in field value
$ go build leaseclaimer.go
leaseclaimer.go:26:2: use of vendored package not allowed
That seems to say something weird about how vendoring and external packages work.
And essentially, you can’t put anything that is vendored into your exposed Methods.
I did come across
https://stackoverflow.com/questions/38091816/packages-type-cannot-be-used-as-the-vendored-packages-type
Which seems to say “yes, you cannot expose vendored packages, so you have to unvendor and put them in GOPATH or change your API to have other methods to build those types”.
That seems like a very big blow towards wanting to use vendoring. I realize we’ve wanted to pull ‘api’ out of the juju source for a while (mostly problematic because Agents use the api as well, and then you run into some serious chicken-and-egg problems with the dependency graph.)
Do go modules do any better here?
Note also that I confirmed GOPATH was at the same revision as the vendor directory. So this is simply that Golang really doesn’t treat the content at “vendor/foo” the same as the content at $GOPATH/foo.
The other cheat for this is if you put your “external” command under the ‘github.com/juju/juju’ directory, but that is certainly not the way to grow helper scripts.
That also seems to be the recommended path if you ever want to edit an upstream dependency. You first just delete it from ‘vendor’ and then hack in $GOPATH.
Maybe the other option is my external source would, itself, use vendoring and then not pay any attention to the github.com/juju/juju vendor directory?
Another interesting interaction with ‘vendor’…
has an ‘init()’ that registers ‘file://’ as a prefix that the default HTTP Transport can handle. However, my external code wants access to our utility: baseTLS := utils.SecureTLSConfig()
but, that leads to 2 copies of ‘github.com/juju/utils’ being loaded. One from GOPATH and one from vendor.
I would have thought that if my project wasn’t vendoring then it wouldn’t pull some files from the vendor/ directory of a different project.