2018-05-27 07:53
浏览 989


When running glide install on my project, I get the following error:

[ERROR] Error scanning cannot find package "." in:
[ERROR] Failed to retrieve a list of dependencies: Error resolving imports

When checking protobuf's source code, I can in fact see that there is no such package. I however don't directly use protobuf, so the error must come from one of the dependencies I use.

When running glide tree on my project, there is only one instance of

|--   (/Users/bevernie/Programmation/work/src/
|   |--   (/Users/bevernie/Programmation/work/src/
|   |   |-- (Recursion)   (/Users/bevernie/Programmation/work/src/
|   |--   (/Users/bevernie/Programmation/work/src/
|   |   |-- (Recursion)   (/Users/bevernie/Programmation/work/src/   (glide get
|--   (/Users/bevernie/Programmation/work/src/
|   |--   (/Users/bevernie/Programmation/work/src/
|   |   |--   (/Users/bevernie/Programmation/work/src/
|   |   |   |-- (Recursion)   (/Users/bevernie/Programmation/work/src/
|   |   |-- (Recursion)   (/Users/bevernie/Programmation/work/src/

which doesn't really help me pinpoint the source of the problem.

Do you have any suggestions as of how to fix the issues?

My project was compiling just fine until a week or two ago (I use Docker to deploy in production, so the glide install was run every time and never failed before that, and I haven't added any new dependency recently).

图片转代码服务由CSDN问答提供 功能建议

在我的项目上运行 glide install 时,出现以下错误:

  [错误]扫描时出错:找不到包“”。 在:

在检查protobuf的源代码时,实际上我可以看到没有这样的软件包。 但是我不直接使用protobuf,因此错误必须来自我使用的依赖项之一。

在项目上运行 glide tree 时,存在 的仅一个实例:

  |  /Users/bevernie/Programmation/work/src/\ N |  |
 |  |  |-(递归)
 |  |
 |  |  |-(递归)  (滑行获取
|--  / ptypes /任意)\ N |  |
 |  |  |
 |  |  |  |-(递归)
 |  |  |-(递归)



我的项目可以编译到一两周前(我使用Docker在生产环境中进行部署,因此 glide install 每次都运行并且从未失败过,并且 我最近没有添加任何新的依赖项)。

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • doushen9863 2018-05-27 08:33

    Before your own PR (995), there was glide issue 968

    It looks like it's caused by a repository's structure changing, i.e. a sub-package being moved, or removed entirely.

    Workarounds proposed by Elliot Wright (seeruk):

    If the package that has been updated is under your own control, then I've since found it easier to use some of the newer Go features like type aliases to ease the pain from refactoring.
    So, instead of just moving a package, move it and then make aliases to the new location in the old one so that your older code still works.
    Then, gradually move things over. Basically just mark things as deprecated but make sure they're still usable for a little while until you've ported new code over.

    If the package is not in your control, then you can always clone the version you want manually to your vendor folder and make your updates in your code.
    Once you're done, Glide should let you update again.
    If it's much more complex, sometimes it's even easier to revert to using go get until you're done updating packages, and rely on your $GOPATH contents.

    It's far from ideal, but there are ways you can work around it at least.
    In the mean time, I've also made an issue about this on dep.
    I think they're looking into a way of disabling this kind of check if you just want the tool to trust you as the developer.

    So you can check if you have the same issue using godep, or even the bleeding-edge vgo.

    解决 无用
    打赏 举报

相关推荐 更多相似问题