你使用的Go版本是什么(go version)?
go version go1.12 linux/amd64你做了什么？
在仓库中运行go get -u命令： https://github.com/tych0/go-bug
$ go get -u
go: gopkg.in/mattn/go-colorable.v0@v0.1.1: go.mod has non-....v0 module path "github.com/mattn/go-colorable" at revision v0.1.1
go: error loading module requirements你期望看到什么？
成功。
你看到了什么？
上面看不懂的错误 :)。
特别是，我实际上遇到这个问题的仓库中有go作为间接依赖项(即gopkg.in/mattn/go-colorable这一行根本不会出现在go.mod中)。然而，错误信息是相同的(它抱怨go.mod,尽管那一行根本不在其中)。
6条答案
按热度按时间axkjgtzd1#
为了澄清，我们可以在这里修复的是错误信息，而不是错误本身。
(
go.mod文件中的module行表示github.com导入路径是规范的，而不是gopkg.in路径。另请参阅 #28489 。)b4qexyjb2#
对于我们这些使用带有这些
gopkg.in导入的包的人来说，有什么解决方法？只能等待上游修复他们的导入吗？rvpgvaaj3#
基本上，是的。(发送PR,避免使用错误上游路径的依赖项。)
您还可能会发现，通过运行带有早于为该依赖项添加
go.mod文件的提交的go get -m gopkg.in/mattn/go-colorable.v0@$COMMIT,可以使事情大致正常工作。这不是一个长期的解决方案，但对于临时修复可能足够了。qij5mzcb4#
它还可以方便地打印出哪个仓库有错误的导入。目前，我必须克隆所有的依赖项并搜索它们。
bmp9r5qi5#
在 #30831 中，我们正在考虑一些机制，让模块通过其他已知的别名来声明它们。这似乎也能帮助解决在这个例子中的
github.com/gopkg.in混淆问题。(但让我们将关于重命名的讨论保留在那里，并将这个问题集中在难以理解的错误信息上。)
omqzjyyz6#
这并非理想状态，但在上游修复其导入问题之前，这是一个相对无痛的解决方法，使用replace。可以使用以下内容。请注意，如果您有依赖项同时使用replace,它们之间不能使用相同的版本。如果go mod有一个
alias关键字来处理这种情况就更好了，这样您只需指向期望它们在新位置的gopkg.in,而人们正在过渡期间。