Recommended workflow when dependency no longer exists?

[lavalamp]

So golang.org/x/net/spdy has been deleted, but our project still has a dependency which uses it. How do you tell godep that it shouldn't try to get a new version of this project? It should keep using the version in its _workspace directory. (For more detail, see kubernetes/kubernetes#7392)

[freeformz]

If you update the paths in your code / Godeps.json file it should just work if the commits are the same. If not I would suggest the following:

1. Checkout the new package (go get it).
2. Update your code to use the new package.
3. Remove the old package from Godeps/Godeps.json
4. run godep save.

[tsuna]

Migrating is obviously the right way to move forward, but I guess what this issue was about, originally, is how can we make godep stop bailing out while we're in the transition period and haven't yet moved to the new import path.

Closing the issue with your advice doesn't really resolve the underlying problem, even though it's (obviously) a sensible advice.

[freeformz]

Maybe (and I'm not convinced this is the right thing to do) we could check to see if we have the commit in the repo first and only try to fetch if we don't have the repo and/or commit?

Otherwise I'm not sure there is anything sensible to do here except bail out so the error can be corrected.

[freeformz]

If we did this and the developer doing godep restore didn't have the repo locally in their $GOPATH we'd still have to fetch it anyway and bail out.

With that said fetching things we don't have is probably a fairly sane thing to do but could greatly complicate things.

Honestly I think failing fast is still probably the best thing here.

What do others think?

[lavalamp]

No, you've both misunderstood the bug report :) There is no new location, and won't ever be one. The package doesn't exist any more, is permanently deleted--the maintainers decided it had bugs they didn't want to fix.

[tsuna]

Sure, well it's the same situation I described, except I made it sound like it was a transitional situation, yours is more permanent, but I think we're asking for the same thing in terms of what godep should do / not bail out.

[freeformz]

@lavalamp Doh!. Well my assertions still apply AFAICT.

@tsuna What would be reasonable for godep to do?

[lavalamp]

I think godep should absolutely check to see if it has the right commit in its local repo before attempting to fetch, FWIW. IIRC we solved this by vendoring outside of godep, which was unusable.

[tsuna]

Maybe with an additional flag godep would print merely a warning and proceed with the missing repo, and just use the local copy. This way it wouldn't bail out with an error.

For instance I recently ran into this when trying to re-build an old tag:

compress/snappy.go:12:2: cannot find package "code.google.com/p/snappy-go/snappy" in any of:
    /usr/local/Cellar/go/1.5.1/libexec/src/code.google.com/p/snappy-go/snappy (from $GOROOT)
    /Users/tsuna/go/src/code.google.com/p/snappy-go/snappy (from $GOPATH)
make: *** [install] Error 1