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

[jayschwa]

What version of Go are you using (go version)?

Go 1.11.1

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Linux, amd64

Problem

Our go.mod has the following dependency, along with many other dependencies:

github.com/sirupsen/logrus v1.1.1

When running go mod vendor, I get the following error:

go: github.com/Sirupsen/logrus@v1.1.1: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

I suspect that some deeper indirect dependency is also using logrus, but with the incorrect (old) capital S. However, the error message isn't giving me enough detail to track it down. It would be nice if the tool gave me a list of the modules or packages that are using the conflicting import path.

Example

https://github.com/jayschwa/go28489

[agnivade]

Have you tried go mod why ?

[myitcv]

The underlying cause here is almost certainly the same as #26208, although per the description, not obviously so. Not least because time (and releases) have passed since that issue was reported.

There are a number of issues/factors at play here:

• github.com/docker/docker does not follow semver so we need to do a separate go get for the latest version of that
• github.com/docker/docker@v17.05.0-ce (for example) is not a module
• github.com/docker/docker@v17.05.0-ce's dependencies are managed via vendor.conf and are sufficiently esoteric (dependencies not using semver, etc) that we need to go mod init and "merge" those dependencies into our main module's go.mod
• github.com/Sirupsen/logrus vs github.com/sirupsen/logrus is a long standing issue. GitHub redirects github.com/Sirupsen/logrus to github.com/sirupsen/logrus
• As of v1.1.0, github.com/sirupsen/logrus/github.com/Sirupsen/logrus is now a module, github.com/sirupsen/logrus. Hence in module mode:

$ go get github.com/Sirupsen/logrus
go: github.com/Sirupsen/logrus@v1.1.1: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

• github.com/Sirupsen/logrus is used as such consistently in github.com/docker/docker@v17.05.0-ce and all its dependencies. This means that any use of github.com/sirupsen/logrus in module mode is a problem (case-insensitive import collision: "github.com/sirupsen/logrus" and "github.com/Sirupsen/logrus") but also that we need to use github.com/Sirupsen/logrus (sic) prior to v1.1.0 when it became the module github.com/sirupsen/logrus

Hence we end up needing to do something like the following (notice we get the pre v1.1.0 version of
github.com/Sirupsen/logrus/github.com/sirupsen/logrus via the gomodmerge):

https://gist.github.com/myitcv/f7270ab81ab45aa286f496264f034b56

To my mind, the v1.1.0 module-enabled release of github.com/Sirupsen/logrus/github.com/sirupsen/logrus is a breaking change; because an import path of github.com/Sirupsen/logrus now no longer works when in module mode (the irony). Hence I think the module release of github.com/Sirupsen/logrus/github.com/sirupsen/logrus should in fact have been a v2 release.

So one potential way forward here is for github.com/Sirupsen/logrus/github.com/sirupsen/logrus to create a new v1 release that reverts the conversion to Go modules and instead release github.com/sirupsen/logrus/v2 as a module.

cc @bcmills and @rsc for any additional thoughts here.

[jayschwa]

Have you tried go mod why?

It produces the same error with no additional info.

github.com/docker/docker does not follow semver so we need to do a separate go get for the latest version of that

I should note that I am using a very recent pseudo-version of docker in my example, and the problem still occurs: github.com/docker/docker v0.7.3-0.20181027010111-b8e87cfdad8d

Ideally, docker should start using go.mod and tag its repo correctly, but in the meantime, it would be nice to get more details from the error message so these sorts of problems are easier to diagnose. Nothing in the error message indicates that the conflict is coming from docker or one of its dependencies.

[myitcv]

I should note that I am using a very recent pseudo-version of docker in my example, and the problem still occurs: github.com/docker/docker v0.7.3-0.20181027010111-b8e87cfdad8d

Indeed, but the issues I listed above are independent of the version of Docker (unless, at some point recently or in the future, Docker and all its dependencies switch to using github.com/sirupsen/logrus as the import path).

Ideally, docker should start using go.mod and tag its repo correctly,

This will help certainly with the "dance" required to get sensible versions of Docker's dependencies, yes.

But that leaves the github.com/Sirupsen/logrus/github.com/sirupsen/logrus issue:

it would be nice to get more details from the error message so these sorts of problems are easier to diagnose

I think this is a particularly subtle edge case. Whilst in general I absolutely agree with the sentiment, I don't know if there's much we can do to generally improve what is likely to be an extremely unlikely confluence of events. But that's just my two cents.

[bcmills]

To my mind, the v1.1.0 module-enabled release of github.com/Sirupsen/logrus / github.com/sirupsen/logrus is a breaking change; because an import path of github.com/Sirupsen/logrus now no longer works when in module mode (the irony).

If you believe that github.com/Sirupsen/logrus was ever a valid import path, then that is correct. 🙂

(At some point we should consider whether we can make import paths case-insensitive, but that's definitely not happening in 1.12.)

A fix for #26904 (comment) would allow you to at least replace github.com/Sirupsen/logrus => github.com/sirupsen/logrus, but that opens a whole other can of case-sensitivity worms.

[bcmills]

So one potential way forward here is for github.com/Sirupsen/logrus/github.com/sirupsen/logrus to create a new v1 release that reverts the conversion to Go modules and instead release github.com/sirupsen/logrus/v2 as a module.

I think it's actually fine to keep the change in v1. Code that uses the “wrong” import path for v1 in is already broken in general anyway: if you try to import the same module with two different cases, you'll get a case-sensitive import collision (#26208 (comment)), so if we allow modules that depend on each path individually build successfully, they still can't be combined: they aren't really “modular”.

[maguro]

It looks like people are working hard to get this fixed correctly. Until then, is there a TL;DR workaround I can use?

[bcmills]

@maguro, a TL;DR workaround to what? The issue reported here is a less-than-helpful error message, but presumably the thing you want to work around is some error itself⸮

[keyolk]

@maguro
in my case I rename all "Sirupsen" to "sirupsen" from my dependencies

[bcmills]

I think the problem here is that we're emitting the error in the wrong place.

If we fetch a module with some casing of its path, and the module declaration indicates a different casing, that's not a defect in the module — it's a defect in whatever package is trying to import from that module, and should be diagnosed within that package.