cmd/go: "unexpected module path" error lacks enough detail to find underlying problem (docker Sirupsen/logrus mismatch) #28489
Comments
|
Have you tried |
|
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:
Hence we end up needing to do something like the following (notice we get the pre v1.1.0 version of https://gist.github.com/myitcv/f7270ab81ab45aa286f496264f034b56 To my mind, the v1.1.0 module-enabled release of So one potential way forward here is for |
It produces the same error with no additional info.
I should note that I am using a very recent pseudo-version of docker in my example, and the problem still occurs: Ideally, docker should start using |
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
This will help certainly with the "dance" required to get sensible versions of Docker's dependencies, yes. But that leaves the
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. |
katiehockman
added
modules
NeedsInvestigation
If you believe that (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 |
I think it's actually fine to keep the change in |
|
It looks like people are working hard to get this fixed correctly. Until then, is there a TL;DR workaround I can use? |
|
@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⸮ |
|
@maguro |
|
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. |
I think a better error would go a long way. I think this is the same issue with
It seems like there is already a reproduction here, but here is a simple one showing CC @vito-c |
|
In #28489 (comment) above, @myitcv has a very nice explanation of the somewhat common issue one can hit with docker with a uppercase/lowercase mismatch between The starting point for that worked example above happens to be a docker version from ~18 months ago (in part because of the way docker has been tagging their releases and moving repos around, as touched upon above), and the worked example above ends up with Here is a worked example using a more recent docker version, and ends up with The following FAQ covers the technique in a bit more detail: First, we clone Worked Example: Steps and Results |
thepudds
changed the title
|
There is some discussion above about making the error friendlier, including to output the parent of the improperly specified dependency (in order to reduce need to then hunt with In addition to that, the current error likely could do a better job describing the issue. As an example, the repo history of docker is a bit confusing, but if you look at Here is current / pre-modules error you get if you try to (That's the "old" error triggered by the enforcement of the import comment). Here's a "simulated" error message IF they had enforced the same thing with a I think the old error is simpler to understand, including the fact that it states what the code "expects" (probably making it simpler to understand than something that is just "unexpected" in the newer error). |
|
Change https://golang.org/cl/158477 mentions this issue: |
|
I just raised the above CL to hopefully improve this error message. I'm looking to become one of the maintainers of |
|
@bcmills to your earlier comment about what the real issue may be[1], I don't think my CL is addressing that as the fix. It's only focused on the value of the error string, and not the location it's being emitted. I marked my CL as a fix for this issue, only because to me it felt like reworking where the error was emitted was maybe a separate (larger) task. This could be a way to improve the error for 1.12, and we could file a separate issue (or rename this one) to speak of a more complete fix. [1] #28489 (comment) |
@theckman, I think your CL makes the error message clearer, and I hope it gets merged. However, discovering where the mismatch is happening in the dependency graph was kind of the crux of this issue when I created it. I don't think it would be accurate to call the CL a fix in its current form. It's also not clear to me what is gained by re-purposing this issue to fit the CL, closing it, and then creating a new issue for the same thing. |
|
@jayschwa ta; adjusted commit to align with that. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
I have a very similar issue with GO 1.12.5 This happens when I run any of go get/go mod why/go mod tidy/go mod verify in the module that wants my-module-name as a dependency. Is there any way to get more information on what went wrong and where the problem actually is? |
|
@BorisKozo Is this portion of the error missing the hostname and full module path:
If not, the issue might be someone has an import statement like:
when it perhaps it should be something more like If it is not obvious where, you could try with the tip version of Go: which in some cases will have a better error message. |
|
@thepudds It wasn't the issue but your comment sent me in the right direction so thank you for that! The problem was that when doing "go mod init" I did I wish the error would be clearer though. |
|
Change https://golang.org/cl/185985 mentions this issue: |
|
Change https://golang.org/cl/186377 mentions this issue: |
Changes "was loaded as" to "was required as". This is slightly more precise, since it hints at a requirement edge in the module version graph. Updates #28489 Change-Id: I636268c33f1ea9858c214fe275f271538186ed6d Reviewed-on: https://go-review.googlesource.com/c/go/+/186377 Run-TryBot: Jay Conrod <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]>
This required bump of some external dependencies, in order to get rid of old versions of logrus as derived depedency. see issues: - sirupsen/logrus#553 - golang/go#28489
This required bump of some external dependencies, in order to get rid of old versions of logrus as derived dependency. see issues: - sirupsen/logrus#553 - golang/go#28489
This required bump of some external dependencies, in order to get rid of old versions of logrus as derived dependency. see issues: - sirupsen/logrus#553 - golang/go#28489
|
if anyone encounters this issue again, a simple solution is to add the following to your Replace the version with whatever you need to use. |
|
I just hit this issue, but the above solution did not work for me. What did work was the solution in this very helpful comment by @kolyshkin: moby/moby#39302 (comment) For me, that meant the following: main.go (or whatever you're using) go.mod cc @leelynne and @lynncyrin |
|
And I was just shown another way around this problem by a colleague (dropping this here for other poor souls who got stuck):
After this the problems disappeared. Main issue were apparently old some old/unused deps causing the clash. |
In 2018 the GitHub "organization" github.com/Sirupsen changed to all lower case. While this was fine in a pre "Go Modules" world, this cases breaking changes when using modules within Go. A number of other Go projects have experienced this, for more detail reference the following: golang/go#28489 golang/go#26208
**What** - Update module replace so that modules _just work_ . This uses the fix described here golang/go#28489 (comment) - This is simpler that the previous fix that required manual edits to the mod file Signed-off-by: Lucas Roesler <[email protected]>
**What** - Update module replace so that modules _just work_ . This uses the fix described here golang/go#28489 (comment) - This is simpler that the previous fix that required manual edits to the mod file Signed-off-by: Lucas Roesler <[email protected]>
**What** - Update module replace so that modules _just work_ . This uses the fix described here golang/go#28489 (comment) - This is simpler that the previous fix that required manual edits to the mod file Signed-off-by: Lucas Roesler <[email protected]>
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.modhas the following dependency, along with many other dependencies:When running
go mod vendor, I get the following error: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
The text was updated successfully, but these errors were encountered: