Dep init fails for github.com/streadway/amqp

[kanishkdudeja]

Dep version: v0.3.2

Dep init fails for github.com/streadway/amqp

No versions of github.com/streadway/amqp met constraints:
master: unable to update repository: : command failed: [git fetch --tags --prune origin]: exit status 255
abrander-no-send-after-shutdown: unable to update repository: : command failed: [git fetch --tags --prune origin]: exit status 255
update-dial-tls-example: unable to update repository: : command failed: [git fetch --tags --prune origin]: exit status 255

[sdboyer]

hi - probably some repository corruption. either rm -rf $GOPATH/pkg/dep/sources and try again, or - if you're willing, this would be great - compile dep from the branch in #1279 and see if it automatically fixes the corruption issue for you.

[kanishkdudeja]

Sorry for the late reply, was caught up with something.

rm -rf $GOPATH/pkg/dep/sources didn't fix the issue. I mean dep init after rm -rf $GOPATH/pkg/dep/sources didn't fix it.

Let me try and compile dep from the branch in #1279 and get back to you.

[kanishkdudeja]

Oops. The last rm -rf $GOPATH/pkg/dep/sources failed since $GOPATH wasn't defined on my system. When I manually ran rm -rf * on the folders inside ~/go/pkg/dep/sources, then dep init ran successfully.

Anyway, is there a way to reproduce the issue? So that I can confirm that the branch in #1279 fixes the issue as well.

Also, dep init added the following packages as well (my code doesn't include them. and they were not present in my earlier vendor directory)

google.golang.org/appengine, github.com/golang/protobuf

Any idea why they got added? I'm fearing longer compilation times because of these added packages.

[sdboyer]

Anyway, is there a way to reproduce the issue? So that I can confirm that the branch in #1279 fixes the issue as well.

unfortunately, no - that's the problem with these cache oddity issues, once they're fixed with the rm -rf sledgehammer, we can't recreate them. and it's tricky to model them in our tests right now, so we...don't do well 😢

Also, dep init added the following packages as well (my code doesn't include them. and they were not present in my earlier vendor directory)

if those are present, it's because something transitively imports them. we don't have the best inspection tools for showing dependers just yet, but if your depgraph isn't too huge, you can see what's doing that via dep status -dot | dot -Tpng -o dep.png, then looking at the generated png.

[kanishkdudeja]

unfortunately, no - that's the problem with these cache oddity issues, once they're fixed with the rm -rf sledgehammer, we can't recreate them. and it's tricky to model them in our tests right now, so we...don't do well 😢

There's one way by which I can try to reproduce the issue:

1. When I first installed dep, my project folder wasn't in the $GOPATH/go/src/ folder. It was in a random folder on my machine. When I ran dep init in that folder, the command failed since it needed my folder to lie inside the $GOPATH/go/src/ folder.
2. At that moment, I thought I'd use the vendor/ folder manually and not use dep. I manually copied all the packages required for my project inside the vendor/ directory in that same folder. I removed those packages from the $GOPATH/go/src/ folder since I wanted to test if Go would pick up those packages from the vendor/ directory. The Go binary failed to compile.
3. Then I copied my project folder into $GOPATH/go/src/ folder and tried compiling my project. It still failed. Then I found out another problem.
4. My packages were imported like ./models or ../config. When I fixed these imports in my codebase to myproject/models or myproject/config, then my project finally compiled without dep (by manually copying the vendor/ folder)
5. Then when I ran dep init, then I faced this issue.

I don't exactly remember if this was the exact flow of events. So it looks like I wasn't following Go conventions (keeping my code in $GOPATH/go/src folder, wrong syntax of importing packages). But I'll try reproducing this on my end and will get back to you if I'm able to.

if those are present, it's because something transitively imports them. we don't have the best inspection tools for showing dependers just yet, but if your depgraph isn't too huge, you can see what's doing that via dep status -dot | dot -Tpng -o dep.png, then looking at the generated png.

Thanks for this. I was able to find out which package needed these 2 dependencies. But I have a silly question, if you don't mind answering. When I had manually done 'go get', these packages did not get imported in my $GOPATH/go/src folder, but my code continued to compile. Can you tell me how did the code compile then?

[kanishkdudeja]

@sdboyer Update: I was able to reproduce the same issue by following the 5 steps mentioned above. Let me know if it helps you in debugging the root cause. or let me know if I can help you debug this more.

[dillon-giacoppo]

Encountered the same issue after accidentally using dep ensure -update as root user. It cached the repository with root permissions only and after dropping out of root:

ensure Solve(): No versions of <PKG> met constraints:
v1.1.15: unable to update repository: : command failed: [git fetch --tags --prune origin]: exit status 255

Tried zapping the cache $GOPATH/pkg/dep and got the permission errors on the .git folder:

rm: ./pkg/dep/sources/https---bitbucket.org-atlassian-go--artifactory/.git/hooks/update.sample: Permission denied

A sudo rm -rf $GOPATH/pkg/dep/sources fixed this for me.

[petrogko]

Having same issue... Running the dep ensure within subdirectory (long story).
I followed these and other solutions. Not really working.
Any advice?