Backward compatible removal of package in dependency can cause godep save error: "no buildable Go source files in <pkg>"

[jpbetz]

Encountered this when upgrading kubernetes from grpc v1.3.0 to v.1.7.4: grpc/grpc-go#1733

Basically what happened is that in v1.3.0 grpc/grpclb/grpc_lb_v1 was a go package, and in v1.7.4, it became an empty directory, but with packages in it's subdirectories, e.g. grpc/grpclb/grpc_lb_v1/messages.

Kubernetes depends on grpc directly as well as indirectly, via docker.

When using godep to upgrade kubernetes to grpc. Kubernetes was changed to directly depend on grpc v1.7.4, but docker still depended on v1.3.0. The upgrade was backward compatible since neither kubernetes nor docker depend on the removed grpc/grpclb/grpc_lb_v1 package, and yet godeps still fails with the error:

godep: no buildable Go source files in /usr/local/google/home/jpbetz/Projects/k8s/src/k8s.io/kubernetes/_output/local/go/src/google.golang.org/grpc/grpclb/grpc_lb_v1                                                                                                                              
 !!! Error in hack/godep-save.sh:69

Since the kubernetes, docker and grpc codebases are complex, I've distilled this down to a minimal case that reproduces the exact issue: https://gist.github.com/jpbetz/2909720a2276a0303ca68f92b776a7c1

Note that if the line 74-76 are uncommented, the test passes.

From the godep save -d output appears that the only dependency godep finds to the removed p3/a package in the reproduction case is from the vendored p3 package at a previous version. Which suggests godep is, at least in this specific case, requiring that package imports in previous version of a project need to validly reference packages in the version of the project actually to be vendored in.

Expected behavior

godep save runs to completion successfully since the package removed is not referenced in any projects depending on it and is backward compatible.

Actual behavior

godep fails with an error like "no buildable Go source files in PACKAGE_NAME".

Steps to reproduce behavior

A minimal reproduction case is captured in this gist: https://gist.github.com/jpbetz/2909720a2276a0303ca68f92b776a7c1

godep version output

godep v79 (linux/amd64/go1.8.1.typealias)

go version output

go version go1.9.1 linux/amd64

Contents of Godeps.json file

godep fails to save an initial Godeps.json

[freeformz]

I am closing this issue because the repo is going to be archived.