[SOLVED] Error when using Go modules in existing project

I started a new project with go modules, the projects already existed. After running go mod int and go mod tidy I’m getting:

go mod tidy
go: downloading [github.com/ghodss/yaml](http://github.com/ghodss/yaml) v1.0.0
go: extracting [github.com/ghodss/yaml](http://github.com/ghodss/yaml) v1.0.0
[go.etcd.io/etcd/discoveryserver/handlers](http://go.etcd.io/etcd/discoveryserver/handlers) imports
[go.etcd.io/etcd/etcdserver/api/v2store](http://go.etcd.io/etcd/etcdserver/api/v2store): module [go.etcd.io/etcd@latest](http://go.etcd.io/etcd@latest) (v3.3.17+incompatible) found, but does not contain package [go.etcd.io/etcd/etcdserver/api/v2store](http://go.etcd.io/etcd/etcdserver/api/v2store)

I have no idea how to solve the module go.etcd.io/etcd@latest (v3.3.17+incompatible) found, but does not contain package go.etcd.io/etcd/etcdserver/api/v2store issue. I would appreciate any help.

2 Likes

would you mind post the contents of the go.mod? Will need to try it out locally here.

2 Likes

This is the go.mod content:

module go.etcd.io/etcd/discoveryserver

go 1.13

require (
	github.com/coreos/etcd v3.3.17+incompatible // indirect
	github.com/google/uuid v1.1.1 // indirect
	github.com/gorilla/handlers v1.4.2
	github.com/gorilla/mux v1.7.3
	github.com/prometheus/client_golang v1.2.1
	github.com/spf13/pflag v1.0.5
	github.com/spf13/viper v1.4.0
	go.etcd.io/etcd v3.3.17+incompatible
	google.golang.org/grpc v1.24.0
	sigs.k8s.io/yaml v1.1.0 // indirect
)
2 Likes

Few probing questions, in sequence:

  1. What’s your GO111MODULE? (cmd: go env GO111MODULE)

  2. Go outside of any go module packages and try export GO111MODULE=on && go get -u github.com/etcd-io/etcd@v3.3.17. Does it work locally?

I can’t reproduce the error here so would need your help on your side. So far I’m able to go get the package without problem.

1 Like

Looks like v2store is not there. I navigate the module folder and it is not. I’m looking at another versions to see if they have the go.etcd.io/etcd/etcdserver/api/v2store package.
$ echo $GO111MODULE -> empty

2 Likes

You’re on auto mode. I just cross-checked their release versions:

v3.3.17 does not have the v2store.

However, v.3.4.2 does have the v2store. Is it okay to move up to v3.4.2?

1 Like

I’ll try the v3.4.2 version, however, the imported version in the code is not from GH:
import ( .... "go.etcd.io/etcd/etcdserver/api/v2store" .... )

2 Likes

Don’t worry about it. You can try with the mirror domain go.etcd.io first, then github.com later if it is not working.

By right, it should be working fine.

1 Like

This is what I get if I try v.3.4.2:

verifying go.etcd.io/etcd@v3.4.2+incompatible/go.mod: go.etcd.io/etcd@v3.4.2+incompatible/go.mod: reading https://sum.golang.org/lookup/go.etcd.io/etcd@v3.4.2+incompatible: 410 Gone

This was done by modifying the go.mod directly.
With go get:

go get -u go.etcd.io/etcd@v3.4.2
go: finding go.etcd.io/etcd v3.4.2
go get go.etcd.io/etcd@v3.4.2: go.etcd.io/etcd@v3.4.2: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3
2 Likes

Oh yes. As expected in go1.13.X. It’s getting strict with the v1, v2, … directory approach. Currently, the project does not practice that directory approach.

Can you try replacing v3.4.2 with its commid ID: bbe86b066c0c714fa2a17ee93a37882553cf2394? They only maintain single master branch (master is always on the edge) so it’s not safe to use @master in this case.

1 Like

I did it with the commit hash and now the go.mod file has:

go.etcd.io/etcd v0.5.0-alpha.5.0.20191009222652-bbe86b066c0c

It is suppose to be v3.4.2. Correct? Also, could you point me out to where I can read about this:
As expected in go1.13.X. It’s getting strict with the v1, v2, … directory approach.

2 Likes

It is expected to have the pseudo-version. You can’t use the tag-version unless the project complies to the version directory approach for tag with major version higher than or equal to 2.

Sure.

Actual Doc:

  1. https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
  2. https://golang.org/doc/go1.13#modules (after understanding of go module’s internal organs)

Q&A:

  1. https://stackoverflow.com/questions/53682247/how-to-point-go-module-dependency-in-go-mod-to-a-latest-commit-in-a-repo/53682399
  2. https://stackoverflow.com/questions/57355929/what-incompatible-in-go-mod-mean-will-it-make-harm (atline explained quite well)

Similar cases:

  1. https://github.com/kataras/iris/issues/1355
  2. https://github.com/kataras/iris/issues/1370

Some Example related to the vX directory:

  1. https://github.com/gizak/termui (notice the v3)

Side-note: if the problem is solved, remember to mark it as “solved” to let others work other problem. =)

1 Like

I’m able to get the server running. I think next thing to do is to fix the compatibility between go modules and the releases. I’ll marked this as resolved and Thank you so much @hollowaykeanho.

2 Likes

Pleasure is mine. :upside_down_face: Feel free to ask again in a separate topic.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.