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

dep init fails if GOPATH has a checked out branch not present in remote #216

Closed
groob opened this Issue Feb 1, 2017 · 5 comments

Comments

Projects
None yet
4 participants
@groob
Copy link
Contributor

groob commented Feb 1, 2017

Today, I tried to run dep init on a new repo https://github.com/groob/autopkgd which resulted in the following errors:

ouchie, solve error: No versions of github.com/groob/plist met constraints:
           empty_data: Unable to update checked out version: fatal: reference is not a tree: 94c3023a0ab2ab1ae7ca10cf1b1416d00c0b77a0

           master: Could not introduce github.com/groob/plist@master, as it is not allowed by constraint empty_data from project github.com/groob/autopkgd.No versions of github.com/groob/plist met constraints:
           empty_data: Unable to update checked out version: fatal: reference is not a tree: 94c3023a0ab2ab1ae7ca10cf1b1416d00c0b77a0

           master: Could not introduce github.com/groob/plist@master, as it is not allowed by constraint empty_data from project github.com/groob/autopkgd.

turns out, $GOPATH/src/github.com/groob/plist had a branch other than master checked out and the changes in that branch were not pushed to github.

git checkout master on the plist repo, and then running dep init again worked.

This issue sounds similar to #158 but I wasn't sure so I'm filing a new issue.

@peterbourgon peterbourgon added the bug label Feb 3, 2017

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Feb 3, 2017

Yeah, thanks for reporting this one. I think this issue is actually the tip of a potentially large iceberg. For every version (branch or tag) we pull from GOPATH, we should ideally:

  1. Verify that the named ref exists in the upstream source; if it doesn't, solve failure is guaranteed
  2. For tags, verify that (if it makes sense for the vcs type), the revision is as expected - e.g., the revision behind tag v1.0.0 is the same as the revision upstream. The solver won't blow up on this case, but it seems probably better to avoid knowingly creating it in the first place if we can, especially given that we haven't sorted out solve warnings yet: sdboyer/gps#77
  3. For anything with a revision, make sure that revision actually exists upstream. This is probably the most common case - unpushed commits.
@paddie

This comment has been minimized.

Copy link

paddie commented Mar 28, 2017

Ran into this one today as well. The issue was an un-pushed commit, but wasn't really clear from the error message.

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Mar 30, 2017

I do want to improve the error here, for sure - there's no reason anyone would realize that that's the problem.

But it's a little arduous to figure out if a commit/ref is unpushed (and across different VCSes!) up front. It might be more productive to do some sniffing on failure to see if the error looks like a local-only data issue.

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Apr 16, 2017

@paddie @groob if either of you still happen to have a case handy for this and wouldn't mind testing with the latest dep to see if there's an improvement, I'd find it to be a great help 😄 I think what'll happen silent success, where the rev from on disk ends up being ignored and the "default" version - latest semver tag if there is one, else default branch) gets selected.

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Apr 28, 2017

We've now got a passable answer for this in the FAQ, so closing this out. Thanks!

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