New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: "unexpected module path" error lacks enough detail to find underlying problem #28489

Open
jayschwa opened this Issue Oct 30, 2018 · 9 comments

Comments

Projects
None yet
7 participants
@jayschwa
Contributor

jayschwa commented Oct 30, 2018

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

This comment has been minimized.

Member

agnivade commented Oct 31, 2018

Have you tried go mod why ?

@myitcv

This comment has been minimized.

Member

myitcv commented Oct 31, 2018

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

This comment has been minimized.

Contributor

jayschwa commented Oct 31, 2018

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

This comment has been minimized.

Member

myitcv commented Oct 31, 2018

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

This comment has been minimized.

Member

bcmills commented Nov 2, 2018

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

This comment has been minimized.

Member

bcmills commented Nov 2, 2018

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

This comment has been minimized.

maguro commented Dec 9, 2018

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

@bcmills

This comment has been minimized.

Member

bcmills commented Dec 10, 2018

@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

This comment has been minimized.

keyolk commented Dec 11, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment