Module Path Error - "github.com/nats-io/nats.go"

[araskachoi]

when I do go get, the output is

go: github.com/go-kit/kit/examples/stringsvc4 imports
        github.com/nats-io/go-nats: github.com/nats-io/go-nats@v1.8.1: parsing go.mod:
        module declares its path as: github.com/nats-io/nats.go
                but was required as: github.com/nats-io/go-nats

looks like it is here that the error is picking up on https://github.com/go-kit/kit/blob/master/examples/stringsvc4/main.go#L16

Any tips/workarounds/fixes?

[peterbourgon]

I have no idea why that's happening. What is your Go version, and are you running go get in your GOPATH, or outside of it?

[sowhyim]

I have no idea why that's happening. What is your Go version, and are you running go get in your GOPATH, or outside of it?

go get don't care about where it run.

[sowhyim]

There is no go.mod in this project.
Why you use go.mod instead gopath?

[bionoren]

I have this same problem. go version go1.13.5 darwin/amd64. I agree with @sowhyim, it shouldn't matter where I run go get. But I get the same error either way - with GOPATH defined and undefined

[wallyqs]

@bionoren do you have a sample of the repo where you are running into this? This could be caused due to a dependency... I sent a PR some time ago to use the nats.go name of the repo, and the only place where this repo potentially references go-nats is in this path in the following test file, since it would be referencing nats-server/v1 which is using go-nats within its own set of tests.

kit/transport/nats/subscriber_test.go

Line 12 in 13ec75b

"github.com/nats-io/nats-server/server"

Rather than updating the path to use "github.com/nats-io/nats-server/server/v2" which I believe would mean adopting Go modules for testing the deps, what I think we could try is to use a toy tcp nats server instead for the transport tests 🤔

[bionoren]

It's also used in the example file that araskachoi linked to: github.com/go-kit/kit/examples/stringsvc4/main.go. In a project using go modules that imports (directly or indirectly) go-kit/kit, if you run go fmt ..., you'll encounter this issue.

Should I be running go fmt ...? Probably not. But it still surprises me that it doesn't work

[peterbourgon]

@sowhyim

go get don't care about where it run.

Well, in Go 1.13...

The GO111MODULE environment variable continues to default to auto, but the auto setting now activates the module-aware mode of the go command whenever the current working directory contains, or is below a directory containing, a go.mod file — even if the current directory is within GOPATH/src. This change simplifies the migration of existing code within GOPATH/src and the ongoing maintenance of module-aware packages alongside non-module-aware importers.

So go get in a directory with no go.mod file in its path ancestry will not be modules-aware, and can fail on packages like github.com/nats-io/nats-server/v2:

~/src/github.com/go-kit/kit (master) go get -v github.com/nats-io/nats-server/v2
github.com/nats-io/nats-server (download)
package github.com/nats-io/nats-server/v2: cannot find package "github.com/nats-io/nats-server/v2" in any of:
        /usr/local/Cellar/go/1.13.5/libexec/src/github.com/nats-io/nats-server/v2 (from $GOROOT)
        /Users/peter/src/github.com/nats-io/nats-server/v2 (from $GOPATH)
~/src/github.com/go-kit/kit (master) _

That's because the /v2 suffix doesn't actually exist in the repo, but is rather an artifact of the Semantic Import Versioning requirement combined path/version magic tricks implemented by modules (I am rolling my eyes extremely hard right now). It can be fixed either by using the "v1" import path without the trailing suffix:

oof ~/src/github.com/go-kit/kit (master) go get -d -u -v github.com/nats-io/nats-server
github.com/nats-io/nats-server (download)
~/src/github.com/go-kit/kit (master) _

Or by explicitly turning on modules mode:

oof ~/src/github.com/go-kit/kit (master) sudo rm -rf ~/pkg/mod/github.com/nats-io
oof ~/src/github.com/go-kit/kit (master) env GO111MODULE=on go get -v github.com/nats-io/nats-server/v2
go: extracting github.com/nats-io/nats-server v1.4.1
go: extracting github.com/nats-io/nats-server/v2 v2.1.2
go: extracting github.com/nats-io/nuid v1.0.1
go: extracting github.com/nats-io/nkeys v0.1.3
go: extracting github.com/nats-io/jwt v0.3.2
~/src/github.com/go-kit/kit (master) _

So I suspect something like that is happening here. But what confuses me is that the offending import path doesn't appear anywhere I can see.

Can someone provide a complete, self-contained example project that demonstrates the problem, including instructions instructions for how to put it on my computer and get the error? I think that will involve: the complete output of go env, the precise location on the filesystem where I should extract the project, and the command(s) I should run.

[peterbourgon]

Rather than updating the path to use "github.com/nats-io/nats-server/server/v2" which I believe would mean adopting Go modules for testing the deps, what I think we could try is to use a toy tcp nats server instead for the transport tests

I would be happy to accept a PR which did this, instead, as long as it was maintainable.

[ChrisHines]

when I do go get, the output is

go: github.com/go-kit/kit/examples/stringsvc4 imports
        github.com/nats-io/go-nats: github.com/nats-io/go-nats@v1.8.1: parsing go.mod:
        module declares its path as: github.com/nats-io/nats.go
                but was required as: github.com/nats-io/go-nats

I have no idea why that's happening. What is your Go version, and are you running go get in your GOPATH, or outside of it?

I don't believe the error message would mention modules if go get was run in GOPATH mode. I cannot reproduce it in GOPATH mode either.

I can reproduce it with a main package that imports the NATS client via its old name, and has a go.mod file. (The NATS Go client repo was renamed from go-nats to nats.go with v1.8.0.) Here is a Go playground reproducer. If you try to run that program in the playground, the output is

go: finding github.com/nats-io/go-nats v1.8.1
go: downloading github.com/nats-io/go-nats v1.8.1
go: extracting github.com/nats-io/go-nats v1.8.1
go: play.ground imports
	github.com/nats-io/go-nats: github.com/nats-io/go-nats@v1.8.1: parsing go.mod:
	module declares its path as: github.com/nats-io/nats.go
	        but was required as: github.com/nats-io/go-nats

The error happens because Github automatically redirects the go tool to the new repository, but at the same time that the repo was renamed a go.mod file was added that specifies the module path as the new name and the go tool rejects it because of the mismatch between the import path in our main program and what the module declares its own base import path to be.

stringsvc4 imported the NATS client via its old name up until 13ec75b.

That leads me to this go-kit specific sequence of reproducing steps that start with checking out a commit of go-kit prior to when the NATS client import paths were updated.

C:\Users\Chris\proj\kit>git checkout e75cc1ab0282c013188f87a858f066ccd6cedbf1
HEAD is now at e75cc1a add test that reproduces data race in sd.endpointCache.updateCache() (#865)

C:\Users\Chris\proj\kit>go mod init github.com/go-kit/kit
go: creating new go.mod: module github.com/go-kit/kit

C:\Users\Chris\proj\kit>cd examples\stringsvc4

C:\Users\Chris\proj\kit\examples\stringsvc4>go get
go: github.com/go-kit/kit/examples/stringsvc4 imports
        github.com/nats-io/go-nats: github.com/nats-io/go-nats@v1.8.1: parsing go.mod:
        module declares its path as: github.com/nats-io/nats.go
                but was required as: github.com/nats-io/go-nats

Of course go-kit doesn't have a go.mod file today, so I had to include a step to add one, but the same would happen with Go 1.13 if there was a go.mod file in any parent directory of the go-kit location.

[ChrisHines]

One correction.

Github no longer redirects requests for go-nats to the nats.go repo because the NATS project has restored the old go-nats repo in an archived state as of the 1.7.2 release. Thus the module path mismatch occurs with Go 1.13 because that version of Go uses the module proxy by default and the module proxy has a snapshot of the go-nats repo taken at a time when the repo had only been renamed and the Github auto redirect was active. That must have been the case up to and including v1.8.1 of the NATS go client. That's why go get tries to get v1.8.1 and not the most recent version, which is v1.9.1.

This can be seen by either using Go 1.12 or setting the environment variable GOPROXY=direct to bypass the Go module proxy containing the bad snapshot. In both cases, the go get that failed in my previous comment works.

Here are some references if you want to read about all the problems the NATS project encountered due to the intersection of a repo rename and Go modules.

nats-io/nats.go#478
nats-io/nats.go#483
golang/go#32483

[theAkito]

setting the environment variable GOPROXY=direct

Fixed it for me. Thanks for the workaround. 👍

[viveksahu26]

setting the environment variable GOPROXY=direct

Fixed it for me. Thanks for the workaround. 👍

Hey @theAkito , can you please help me to set the same environment in windows. I have also similar issue.