vgo tends to choose an old version of docker/docker due to the vgo requirement for semantic import versioning. (The latest docker tags are for v17, but without a versioned import path vgo stops at v1.)

That's probably giving you some transitive dependency that uses a bad import path for logrus.

What happens if you explicitly vgo get github.com/docker/docker@v17.05.0-ce?

Hi @bcmills, thanks for the suggestion, but I got the same error

EDIT - to be clear, I first $ vgo get github.com/docker/docker@v17.05.0-ce and then $ vgo build ./...

I'm also hitting this in another project @bcmills - one with a very long list of dependencies, including docker and some other large things. It's unclear where the problem comes from, or how to determine it.

I have also reproduced @adam's experience.

When we stop automatically picking old versions of things (#26238) it should pretty much go away. Let's revisit once that is fixed.

Thanks @bcmills! I'll keep an eye on that issue and try again once closed.

#26238 was merged. Is this issue still happening?

@filewalkwithme trying to install from source to check, now. Having some issues but will update you with progress, soon.

@filewalkwithme same problem, unfortunately.

$ go version
go version devel +859a944ee2 Wed Aug 1 21:45:11 2018 +0000 linux/amd64

$ git clone git@github.com:adam-hanna/vgo-bug.git && cd vgo-bug
$ go build .
/home/adam/go/pkg/mod/github.com/docker/go-events@v0.0.0-20170721190031-9461782956ad/broadcast.go:7:2: case-insensitive import collision: "github.com/sirupsen/logrus" and "github.com/Sirupsen/logrus"

The root cause here is using such an old version of docker that it pulls in the very old github.com/Sirupsen/logrus, alongside something else that pulls in the newer github.com/sirupsen/logrus. The collision detection is correct, the problem is the bad configuration that causes the collision.

This is not going to change for Go 1.11. We did make the module support better at understanding when a v2.0.0 tag should be considered an incompatible part of the v1 sequence. But docker does not even use valid semver tags, so that didn't help. (v17.05.0-ce is not the "-ce" prerelease of v17.05.0, and more to the point v17.05.0 is not a valid semver version, since the positive numbers can't have leading zeros. It would have to be v17.5.0.)

@rsc Thanks for the help!

Unless I'm mistaken, the example repo is using the most recent release of docker (v17.03.2-ce). The git hash of which is f5ec1e2936dcbe7b5001c2b817188b095c700c27

In go.mod, line #15:

require(
...
github.com/docker/docker v0.0.0-20170601211448-f5ec1e2936dc
...
)

You can see that that is in fact the latest git hash.

EDIT - Scratch the first part of my comment...

Would it be possible to consider adding support for:

replace github.com/Sirupsen/logrus v1.0.5 => github.com/sirupsen/logrus v1.0.5

??

Thanks!

EDIT 2 -
I can confirm that using v17.05.0 works.

It may be worth looking at the corpus to see which major packages vendor an old docker version (pre July 2017). If the responsibility lies with the package maintainers themselves then starting the outreach sooner rather than later will give those package maintainers more time to anticipate the issue.

Also maybe I'm reading this wrong but is there any temporary workaround for those project maintainers who themselves are depending on a package that in turn depends on an old version of docker except for "don't use go mod for dependency management"?

FYI I did this in a repo which depends on github.com/hyperledger/fabric which depends on an old version of docker as a workaround and the error went away:

go mod init
go get github.com/docker/docker@v0.0.0-20180422163414-57142e89befe
go test ./...

No manual editing of go.mod required. Tested in fresh golang:rc container.

I'm not sure if github.com/hyperledger/fabric will actually work with docker@v0.0.0-20180422163414-57142e89befe but at least the go tooling will work.

More recent discussion (along with worked examples of good techniques to resolve properly):

• cmd/go: "unexpected module path" error lacks enough detail to find underlying problem (docker Sirupsen/logrus mismatch) #28489 (comment)
• cmd/go: "unexpected module path" error lacks enough detail to find underlying problem (docker Sirupsen/logrus mismatch) #28489 (comment)

Would it be possible to consider adding support for:

replace github.com/Sirupsen/logrus v1.0.5 => github.com/sirupsen/logrus v1.0.5

That will likely be allowed once #26904 is addressed. Closing this issue as subsumed by that one.