[SOLVED] Error when using Go modules in existing project

etua · October 23, 2019, 1:11am

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.

hollowaykeanho · October 23, 2019, 1:28am

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

etua · October 23, 2019, 1:43am

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
)

hollowaykeanho · October 23, 2019, 2:06am

Few probing questions, in sequence:

What’s your GO111MODULE? (cmd: go env GO111MODULE)
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.

etua · October 23, 2019, 2:12am

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

hollowaykeanho · October 23, 2019, 2:22am

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?

etua · October 23, 2019, 2:27am

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" .... )

hollowaykeanho · October 23, 2019, 2:36am

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.

etua · October 23, 2019, 2:40am

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

hollowaykeanho · October 23, 2019, 2:51am

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.

etua · October 23, 2019, 3:04am

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.

hollowaykeanho · October 23, 2019, 3:13am

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:

Modules · golang/go Wiki · GitHub
Go 1.13 Release Notes - The Go Programming Language (after understanding of go module’s internal organs)

Q&A:

git - How to point Go module dependency in go.mod to a latest commit in a repo? - Stack Overflow
go modules - What does 'incompatible' in go.mod mean, will it cause harm? - Stack Overflow (atline explained quite well)

Similar cases:

Some Example related to the vX directory:

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. =)

etua · October 23, 2019, 3:23am

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.

hollowaykeanho · October 23, 2019, 3:24am

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

system · January 21, 2020, 3:24am

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