What does 'incompatible' in go.mod mean, will it cause harm?

Question

I'm using goczmq in my project, something like next:

main.go:

package main

import (
    _ "github.com/zeromq/goczmq"
)

func main() {
}

And more, I'm using golang 1.12 with gomod to manage my project.

See next, I use go mod init xxx, and when build, it downloads goczmq automatically for me and add dependency to go.mod, but has incompatible in it. (But for other library I may get something like github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181)

go.mod:

module pigeon

go 1.12

require (
    github.com/zeromq/goczmq v4.1.0+incompatible
)

From some discussion (for other library), e.g. this, it seems the library owner should do something to support golang 1.12? But in my case, all things works fine just a incompatible there make me a little worried (I mean all seems ok now, but some day when I use an api which I never used before, there will be hidden bomb there...?)

So my question:

Should I worry about this, or this is just as expected?

Seagraves

Answer 1

+incompatible means the dependency has a semver major version of 2 or higher and is not a Go module yet (it doesn't have go.mod in its source code).

Tyrannize

But github.com/kolo/xmlrpc also not have go.mod, but as mentioned in my post, it did not show incompatible. – Seagraves

I've edited to anser to include that +incompativle is only used for v2+. It's incompatible since a "proper" Go module would have a …/v4 in the module name if it was "v4.1.0". – Brillatsavarin

Also see github.com/golang/go/wiki/… – Brillatsavarin

Will that cause any issue in future? if go.mod does not exist? – Ernaldus

Answer 2

Accepted answer is correct, but really not friendly for me who just get in touch with go module. I made some investigation base on the answer & make a conclusion base on this as next, in case anyone needed:

Standard commands like go build or go test will automatically add new dependencies as needed to satisfy imports (updating go.mod and downloading the new dependencies). But there are several different situations which will result in the different version selections:

1. If a repository has not opted in to modules but has been tagged with valid semver tags, meanwhile, it's v0/v1 module, see this:

   not opted in to modules: means no go.mod in source tree

   valid semver tags: means the repo use git tag to tagged as something like vX.Y.Z

   v0/v1 module: means the value of major version(that is X) is 0 or 1, e.g. v0.1.0, v1.2.3

   Then, it will use a pseudo-version, something like github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181

2. If a repository has not opted in to modules but has been tagged with valid semver tags, meanwhile, it's a v2+ module, see this:

   v2+ module: means the value of major version(that is X) is >=2,e g. v4.1.0

   Then, it will show as incompatible, something like github.com/zeromq/goczmq v4.1.0+incompatible

3. If a repository has already opted in to modules, but not have been tagged with valid semver tags:

   Then, it will behave as 1, use pseudo-version.

4. If a repository has already opted in to modules, and has been tagged with valid semver tags, meanwhile, it's a v0/v1 module:

   Then, it will behave normally like github.com/stretchr/testify v1.3.0

5. If a repository has already opted in to modules, and has been tagged with valid semver tags, meanwhile, it's a v2+ module:

   Then, when import in sourcecode, we need add /vN at the end, e.g., import "github.com/my/mod/v4", and in go.mod it will behave like github.com/my/mod/v4 v4.1.0

Seagraves

for #5, does this means we have to create a new folder or project for /v4 (since this is a github repository) for it? Or is it that we just add the suffix /v4 to just indicate its version is v2+ without actual folder? – Pundit

No physical folder needed. Give you a example: This project github.com/etcd-io/etcd/blob/master/go.mod#L9 need to use github.com/coreos/go-systemd/v22 v22.0.0, but next is the project coreos: github.com/coreos/go-systemd, you could see it did not have a folder v22.0.0, just have it in module name: github.com/coreos/go-systemd/blob/master/go.mod#L1 – Seagraves

What do you mean by "opted in to modules"? That there is a go.mod file or something else? – Seawright

@S.Yacko YES, with go.mod, more precisely using go modules, see go.dev/blog/using-go-modules – Seagraves

Answer 3

The module name should have been github.com/zeromq/goczmq/v4 instead of github.com/zeromq/goczmq for versions v4 and above (v4.1.0, v4.2.0, etc).

Since github.com/zeromq/goczmq has not adopted Go modules correctly, the go get will fail if Go 1.13 is used and the GOPROXY is set to direct or to some other server that does not host this file -

    go get github.com/zeromq/[email protected]+incompatible
    go: finding github.com v4.2.0+incompatible
    go: finding github.com/zeromq v4.2.0+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go get github.com/zeromq/[email protected]+incompatible: github.com/zeromq/[email protected]+incompatible: invalid version: +incompatible suffix not allowed: module contains a go.mod file, so semantic import versioning is required

More details mentioned under the 'Version validation' section here - https://golang.org/doc/go1.13#modules

Note - GoSUMDB also won't have such entries so even if you set the GOPROXY to a server that hosts this file and if GOSumDB is enabled, then you will get something like this -

    ➜  ~ export GOPROXY=https://gocenter.io
    ➜  ~ go get github.com/zeromq/[email protected]+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go: finding github.com/zeromq v4.2.0+incompatible
    go: finding github.com v4.2.0+incompatible
    go: downloading github.com/zeromq/goczmq v4.2.0+incompatible
    verifying github.com/zeromq/[email protected]+incompatible: github.com/zeromq/[email protected]+incompatible: reading https://gocenter.io/sumdb/sum.golang.org/lookup/github.com/zeromq/[email protected]+incompatible: 404 Not Found

The correct solution will be to follow up with the module author to make sure that they are adopting Go modules correctly by adding a suffix to the module name.

There is a workaround but have to check if it's working by design i.e. point GOPROXY to a server that hosts this file and then use GOPRIVATE to exclude this specific module version from GoSumDB validation -

    root@715c3b39bb12:/go# export GOPROXY=https://gocenter.io 
    root@715c3b39bb12:/go# unset GOPRIVATE

    root@715c3b39bb12:/go# go get github.com/zeromq/[email protected]+incompatible
    go: finding github.com v4.2.0+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go: finding github.com/zeromq v4.2.0+incompatible
    go: downloading github.com/zeromq/goczmq v4.2.0+incompatible
    verifying github.com/zeromq/[email protected]+incompatible: github.com/zeromq/[email protected]+incompatible: reading https://gocenter.io/sumdb/sum.golang.org/lookup/github.com/zeromq/[email protected]+incompatible: 404 Not Found

    root@715c3b39bb12:/go# export GOPRIVATE=github.com/zeromq/goczmq

    root@715c3b39bb12:/go# go get github.com/zeromq/[email protected]+incompatible

    go: downloading github.com/zeromq/goczmq v4.2.0+incompatible
    go: extracting github.com/zeromq/goczmq v4.2.0+incompatible
    # pkg-config --cflags  -- libczmq libzmq libsodium
    Package libczmq was not found in the pkg-config search path.
    Perhaps you should add the directory containing `libczmq.pc'

However, will still recommend reaching out to the module author to fix the module name in their go.mod file.

Enceinte