如何使Go模块语义导入版本控制v2 +与虚荣导入路径一起使用

Question

We are trying to migrate our Go code base to go modules and I can't figure out how to make it work with vanity import paths.

---

With dep

Until now our dependency management tool has been dep. We would place a Gopkg.toml file in our project root, and would define a dependency like:

[[constraint]]
  name = "mycompany.com/some-lib"
  version = "3.0.0"

As you can see, we use a so-called vanity import path for our own packages. In fact, our code is actually hosted on a private git server altogether.
So along with this, we set up another server that renders HTML meta tags with repository information. E.g.:

<meta 
    name="go-import" 
    content="mycompany.com/some-lib git https://mygitserver.com/some-lib"
>

The mechanism is basically the one described in cmd/go docs, Remote import paths.

---

With go modules

So with go modules instead I have export GO111MODULE=on and a go.mod file that requires a dependency according to semantic import versioning:

module foo

go 1.13

require (
    mycompany.com/some-lib/v3 v3.0.0
)

Note that the import path has the v3 suffix as required by semantic import versioning. And the some-lib project also has its own go.mod file starting with: module mycompany.com/some-lib/v3.

Now my problem is that when go get or go build the dependency resolution fails with:
go: mycompany.com/some-lib/v3@v3.0.0: unrecognized import path "mycompany.com/some-lib/v3" (parse https://mycompany.com/some-lib/v3?go-get=1: no go-import meta tags ())

Of course this happens, because my remote import server handles mycompany.com/some-lib but not mycompany.com/some-lib/v3.

---

Question

• Isn't go command able to handle versioned imports automatically? I thought it would query for mycompany.com/some-lib and then fetch v3 by itself.
• Am I supposed to handle every single /vN route in my remote import server?
• If so, what should I write in the <meta> tag? If not, what should I do?

Bonus info: I've seen some docs and articles recommending to basically duplicate the code under directories named after major versions, something like:

/               ---> contains v1.x.y code
|_ main.go
|_ interface.go
|_ go.mod
|_ /v2          ---> contains v2.x.y code
    |_ main.go
    |_ interface.go
    |_ go.mod

Or alternatively to maintain separate branches for each major version.
I don't want to do this. And I want to require mycompany.com/some-lib/v3 v3.0.0 or require mycompany.com/some-lib/v4 v4.1.0 based on each client project needs and fetch versions from the same place just as I did with dep.

Bonus info 2: curiously enough, ALL our project third-party dependencies either are not on go modules or are still on v0 or v1 versions or just hosted on github, so I can't find applicable examples.

Any insight is extremely appreciated. Thank you.

Answer 1

Am I supposed to handle every single /vN route in my remote import server?

Yes. (You are already supposed to handle every path that may correspond to a package within the repository: see https://golang.org/cmd/go/#hdr-Remote_import_paths.)

If so, what should I write in the <meta> tag?

Exactly the same thing that you are writing today should work: the same paths, with no /vN suffix needed unless you want to route different versions to different repositories.