consul/watch doesn´t exists

[xleyba]

Overview of the Issue

When compiling micro package I received the error:

../go-micro/registry/consul/watcher.go:8:2: cannot find package "github.com/hashicorp/consul/watch" in any of:
/usr/local/go/src/github.com/hashicorp/consul/watch (from $GOROOT)
/Users/jleyba/go/src/github.com/hashicorp/consul/watch (from $GOPATH)

When checking into hasicorp consul/watch I realized it is importing

consulwatch "github.com/hashicorp/consul/watch"
"github.com/mitchellh/cli"

That do not exists.

Reproduction Steps

1. Try to compile micro package or check consul code

[banks]

Hey thanks, the package still does exist (https://github.com/hashicorp/consul/tree/master/watch) however we didn't export it separately in our recent switch to go mod so it doesn't have it's own mod file.

We choose to make /api a separate package with separate versioning. Will need to work out the best way to solve this for downstream dependencies.

Can you say whether you are using Go Modules? Which version of Go? DO you have GO111MODULES set? In or out of GOPATH?

[banks]

CC @jefferai FYI

[xleyba]

Hi

Thanks for your answer.

I am new in Go and just starting with micro services by using go-micro.
I have tried to compile micro package in order to use such tool to generate
a micro service template and then go the error.
Seem that go-micro is using consul/watch…

Regarding the version of Go, this is what my Mac say:

Javiers-MacBook-Air:micro jleyba$ go version
go version go1.12.1 darwin/amd64

I do not have GOMODULES set.

On 4 April 2019 at 12:04:33, Paul Banks ([email protected]) wrote:

Hey thanks, the package still does exist (
https://github.com/hashicorp/consul/tree/master/watch) however we didn't
export it separately in our recent switch to go mod so it doesn't have it's
own mod file.

We choose to make /api a separate package with separate versioning. Will
need to work out the best way to solve this for downstream dependencies.

Can you say whether you are using Go Modules? Which version of Go? DO you
have GO111MODULES set? In or out of GOPATH?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479834670,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIR7xo6cVnQwC5dkyE0N2MH_gp3YgzIks5vdc4xgaJpZM4ccZE9
.

[banks]

Thanks!

Are you attempting to compile go-micro from inside your GOPATH? If you
aren't sure, try echo $GOPATH and check if go-micro is inside
$GOPATH/src/github.com/micro/go-micro.

On Thu, Apr 4, 2019 at 11:10 AM xleyba [e-mail] wrote:

Hi

Thanks for your answer.

I am new in Go and just starting with micro services by using go-micro.
I have tried to compile micro package in order to use such tool to generate
a micro service template and then go the error.
Seem that go-micro is using consul/watch…

Regarding the version of Go, this is what my Mac say:

Javiers-MacBook-Air:micro jleyba$ go version
go version go1.12.1 darwin/amd64

I do not have GOMODULES set.

On 4 April 2019 at 12:04:33, Paul Banks ([email protected]) wrote:

Hey thanks, the package still does exist (
https://github.com/hashicorp/consul/tree/master/watch) however we didn't
export it separately in our recent switch to go mod so it doesn't have it's
own mod file.

We choose to make /api a separate package with separate versioning. Will
need to work out the best way to solve this for downstream dependencies.

Can you say whether you are using Go Modules? Which version of Go? DO you
have GO111MODULES set? In or out of GOPATH?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479834670,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAIR7xo6cVnQwC5dkyE0N2MH_gp3YgzIks5vdc4xgaJpZM4ccZE9
>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479836683,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHYUzlSbcl7DIorA1em2d5s0VAxA5lEks5vdc-jgaJpZM4ccZE9
.

[xleyba]

Hi

Yes, this is my GOPATH. ->. GOPATH="/Users/jleyba/go”

And here is where I am trying to run go build:

Javiers-MacBook-Air:micro jleyba$ pwd
/Users/jleyba/go/src/github.com/micro/micro

J

On 4 April 2019 at 14:11:17, Paul Banks ([email protected]) wrote:

Thanks!

Are you attempting to compile go-micro from inside your GOPATH? If you
aren't sure, try echo $GOPATH and check if go-micro is inside
$GOPATH/src/github.com/micro/go-micro.

On Thu, Apr 4, 2019 at 11:10 AM xleyba [e-mail] wrote:

Hi

Thanks for your answer.

I am new in Go and just starting with micro services by using go-micro.
I have tried to compile micro package in order to use such tool to
generate
a micro service template and then go the error.
Seem that go-micro is using consul/watch…

Regarding the version of Go, this is what my Mac say:

Javiers-MacBook-Air:micro jleyba$ go version
go version go1.12.1 darwin/amd64

I do not have GOMODULES set.

On 4 April 2019 at 12:04:33, Paul Banks ([email protected]) wrote:

Hey thanks, the package still does exist (
https://github.com/hashicorp/consul/tree/master/watch) however we didn't
export it separately in our recent switch to go mod so it doesn't have
it's
own mod file.

We choose to make /api a separate package with separate versioning. Will
need to work out the best way to solve this for downstream dependencies.

Can you say whether you are using Go Modules? Which version of Go? DO you
have GO111MODULES set? In or out of GOPATH?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479834670,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAIR7xo6cVnQwC5dkyE0N2MH_gp3YgzIks5vdc4xgaJpZM4ccZE9
>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479836683,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAHYUzlSbcl7DIorA1em2d5s0VAxA5lEks5vdc-jgaJpZM4ccZE9

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479871529,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIR7wxe8SLC-4YJr5-MDKHzCKqszw_Mks5vdevjgaJpZM4ccZE9
.

[banks]

Looks like go-micro recently updated to use go modules as well and has
the correct deps for Consul to work:
https://github.com/micro/micro/blob/master/go.mod

I think the issue is that you are trying to build go-micro with go modules
OFF (because you are in GOPATH and it defaults to off there).

You can either force it on with GO111MODULES=on go build or move the
go-micro out of your GOPATH and build, either should work.

Can you let me know as it's not really a Consul issue - if that works you
might consider making an issue or PR for go-micro to update their README
and docs to point out that it won't build without go mod enabled now?

On Thu, Apr 4, 2019 at 1:43 PM xleyba [e-mail] wrote:

Hi

Yes, this is my GOPATH. ->. GOPATH="/Users/jleyba/go”

And here is where I am trying to run go build:

Javiers-MacBook-Air:micro jleyba$ pwd
/Users/jleyba/go/src/github.com/micro/micro

J

On 4 April 2019 at 14:11:17, Paul Banks ([email protected]) wrote:

Thanks!

Are you attempting to compile go-micro from inside your GOPATH? If you
aren't sure, try echo $GOPATH and check if go-micro is inside
$GOPATH/src/github.com/micro/go-micro http://github.com/micro/go-micro
.

On Thu, Apr 4, 2019 at 11:10 AM xleyba [e-mail] wrote:

Hi

Thanks for your answer.

I am new in Go and just starting with micro services by using go-micro.
I have tried to compile micro package in order to use such tool to
generate
a micro service template and then go the error.
Seem that go-micro is using consul/watch…

Regarding the version of Go, this is what my Mac say:

Javiers-MacBook-Air:micro jleyba$ go version
go version go1.12.1 darwin/amd64

I do not have GOMODULES set.

On 4 April 2019 at 12:04:33, Paul Banks ([email protected])
wrote:

Hey thanks, the package still does exist (
https://github.com/hashicorp/consul/tree/master/watch) however we didn't
export it separately in our recent switch to go mod so it doesn't have
it's
own mod file.

We choose to make /api a separate package with separate versioning. Will
need to work out the best way to solve this for downstream dependencies.

Can you say whether you are using Go Modules? Which version of Go? DO you
have GO111MODULES set? In or out of GOPATH?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/hashicorp/consul/issues/5604#issuecomment-479834670
,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAIR7xo6cVnQwC5dkyE0N2MH_gp3YgzIks5vdc4xgaJpZM4ccZE9

>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/hashicorp/consul/issues/5604#issuecomment-479836683
,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAHYUzlSbcl7DIorA1em2d5s0VAxA5lEks5vdc-jgaJpZM4ccZE9
>

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479871529,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAIR7wxe8SLC-4YJr5-MDKHzCKqszw_Mks5vdevjgaJpZM4ccZE9
>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/consul/issues/5604#issuecomment-479881192,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHYU0LmYWGxf5epfJuKgf5G-i7RuxTtks5vdfNVgaJpZM4ccZE9
.

[sneat]

Hi @banks we've run into this issue as well, and was actually part way through putting together an example app showing the issue when we noticed the existing report.

What we've found is that it's only the master branch that has the issue, the v1.4.4 tag is fine. The reason it's a problem is because there are 2 packages that match the []*api.ServiceEntry type that go-micro tries to cast to (https://github.com/micro/go-micro/blob/master/registry/consul/watcher.go#L53).

The two packages exist because of the vendoring of consul itself within consul. Note that https://github.com/hashicorp/consul/tree/master/vendor/github.com/hashicorp/consul exists in master but not in the v1.4.4 tag (https://github.com/hashicorp/consul/tree/v1.4.4/vendor/github.com/hashicorp).

In go-micro it imports and uses the github.com/hashicorp/consul/api package, but it looks like internally in master you've started using github.com/hashicorp/consul/vendor/github.com/hashicorp/consul/api and so the type cast at https://github.com/micro/go-micro/blob/master/registry/consul/watcher.go#L53 fails.

This could all be related to the watch package not being gomod'd possibly? Not sure how the interaction works there.

It's worth also noting that we are actually using a fork of go-micro that is does not have the gomod support added (and updating our fork is not a quick or simple process) so the above cause/resolution doesn't directly apply. We also believe that any project using consul watchers that does not implement gomod will have the same issue we have.

Using go 1.11.x and specifying GO111MODULE=off go build does correct allow it to build, as setting that seems to force it to also not use the vendor directory. Note that go 1.12.x doesn't seem to support/respect this flag, so you can't actually build with go 1.12.x and have the checkout in your $GOPATH even though the output of of a modules check is:

go list -m all
go list -m: not using modules

In summary, our options are:

• Get Consul to not vendor itself (what we'd like)
• Modify the watch package so that it uses the github.com/hashicorp/consul/api package rather than the vendor'd one (alternatively what we'd like)
• Build using go 1.11.x and specify the GO111MODULE=off (having implemented an example package demonstrating the issue, it has become clear that this workaround doesn't work)
• Force Consul to branch tags/v1.4.4 prior to building (current workaround)
• Move everything out of $GOPATH prior to utilising go 1.12.x (a lot of work and not backwards compatible)

---

We finished putting together the example anyway which shows the issue: https://github.com/sneat/consulwatchexample

Commit https://github.com/hashicorp/consul/commit/28c84845bf082f07724217cd198d5f119009417f specifically is the one that "broke" it for us.

While finishing this off we noticed that varying the values of GO111MODULE didn't actually change whether it works or not, so our current workaround may not actually be working as we expect.

[richjddavis]

Further to @sneat's explanation, I've whipped up an "in spirit" reproduction of the issue here: https://github.com/richjddavis/consul-vendoring-reproduction. It doesn't actually depend on the real consul package, but hits the same issue by approximation:

1. consul vendors consul/api
2. consul/watch uses vendored version of consul/api
3. consul/watch returns a ServiceEntry type (consul/vendor/github.com/hashicorp/consul/api/api.ServiceEntry) that's incompatible with the "real" ServiceEntry (consul/api/api.ServiceEntry)
4. Any external code that is using consul/watch and expecting to resolve a handled message to a concrete api.ServiceEntry type will be unable to do so

In the case of the "reproduction":

1. consulish vendors consulish/api
2. consulish/watch uses vendored version of consulish/api
3. consulish/watch returns a ServiceEntry type (consulish/vendor/github.com/richjddavis/consul-vendoring-reproduction/consulish/api/api.ServiceEntry) that's incompatible with the "real" ServiceEntry (consulish/api/api.ServiceEntry)
4. Any external code that is using consul/watch and expecting to resolve a handled message to a concrete api.ServiceEntry type will be unable to do so

Sorry that it's not using the actual package: it was a bit quicker for me to do this than to stand up everything I'd need to prove it otherwise.

Checking out tag v1.4.4 resolves the issue, as it doesn't self-vendor. Ideally, we wouldn't have to pin consul ourselves (by vendoring or moving to Go modules) to avoid this.

[xleyba]

Thanks guys.
I have followed your advise and compiled it outside the GOPATH and worked fine.

I have also droped a message on go-micro github and mention this ticket to help them to identify/solve the issue but seems nobody is checking issues there... :(

Thanks a lot.
J

[banks]

@sneat @richjddavis thanks for the info here.

What we've found is that it's only the master branch that has the issue, the v1.4.4 tag is fine

Sadly that's because 1.4.4 was cut before we made the go mod changes. Our next release will presumably break things for you for good.

Using go 1.11.x and specifying GO111MODULE=off go build does correct allow it to build, as setting that seems to force it to also not use the vendor directory. Note that go 1.12.x doesn't seem to support/respect this flag

Go 1.12.1 does still support GO111MODULE but I _think_ the behaviour you were observing before (ignoring vendoring) was considered a bug and is now fixed!

The two packages exist because of the vendoring of consul itself within consul.

This is tricky. Long term we'd like to not vendor anything and rely on go.mod. Sadly it doesn't seem responsible to do that until we have a mechanism to not rely on thirdpartys in our core product build chain. For example in a left-pad, like situation it seems like a big risk to not be able to build any more.

Maybe there is a way (or should be a way) to prevent go mod vendor from self-vendoring when you need to export a separate API package but AFAIK the Go team have generally been reluctant to add complications to support multi-module repos even though it seems the only practical option for existing projects like ours that relied on sub-packages being imported individually.

We are still trying to figure out the best option here but given that go mod vendor seems necessary for now and results in the current vendoring behaviour, it's not very obvious what the least-bad option is.