Now module major version use / as a separator when parsing modfile.
such as github.com/oiooj/agent/v2.

Should we add . as a separator for compatibility with gopkg.in ?
such as gopkg.in/yaml.v2

But I don't think this is a good idea. Because domains use . as their separator.
such as service.v6.ifeng.com/api/client.v6

@rsc

@oiooj, see golang/vgo@84430ca.

I have the very same issue but I don't understand exactly what is the cause.
Is it because of the convention that the modules from version 2 should be in a "/2" subdirectory?
If yes, shouldn't it only be a "suggested convention"? What happens if I release v2 of a project but I don't want to change the structure of my repository?
I don't see any technical reason why this should be enforced, am I missing something?

The same issue is present for many libraries, e.g.:
vgo: parsing downloaded go.mod: go.mod:12: invalid module: gopkg.in/go-playground/validator.v8 should be v1, not v8 (v8.0.0-20160110003959-c193cecd124b)

Waiting for this to be fixed, is there a workaround for it?

@ufoscout What version of vgo are you seeing that at? The change for gopkg.in versioning is fairly recent.

What happens if I release v2 of a project but I don't want to change the structure of my repository?

See https://research.swtch.com/vgo-module. (Search for the section labeled “From Repository to Modules”.)

I am getting the same error:

1. Did a fresh go get -u -v golang.org/x/vgo as of 3:40est 4/30/2018
2. run vgo build ./...
3. vgo: errors parsing go.mod: invalid module: gopkg.in/yaml.v2 should be v1, not v2 (v2.2.1)

@bcmills

What version of vgo are you seeing that at? The change for gopkg.in versioning is fairly recent.

I did this right now:

$ go get -u golang.org/x/vgo

$ vgo version
go version go1.10.1 linux/amd64 vgo:2018-02-20.1

$ vgo build
vgo: finding github.com/gin-contrib/static v0.0.0-20180301030858-73da7037e716
vgo: finding github.com/gin-gonic/gin v1.1.4
vgo: finding github.com/gin-gonic/gin v1.1.4
vgo: parsing downloaded go.mod: go.mod:12: invalid module: gopkg.in/go-playground/validator.v8 should be v1, not v8 (v8.0.0-20160110003959-c193cecd124b)

I can confirm the same issue for go-mgo/mgo:

vgo: parsing downloaded go.mod: go.mod:22: invalid module: gopkg.in/mgo.v2 should be v1, not v2 (v2.0.0-20160818020120-3f83fa500528)

vgo can not parsed modulepath correctly with gopkg.in before. This issue was fixed by CL 112277.

@oiooj

The ticket is about the vague error message, not the functionality (which does appear to be working now... see #24099 ). I didn't see any fix for error messages like the following

vgo: parsing downloaded go.mod: go.mod:58: invalid module: ....

so it's clear which go.mod is the problem

@client9 Because vgo can not parsed modulepath correctly with gopkg.in, so you got the confused error message. No need to fix error message.