dep ensure with noverify should not fail if go-import metadata can not be read

[drcrallen]

There is a nasty problem with Github Enterprise where, if the portal is redirected to a login style page, it is not possible to use dep ensure to keep any dependencies in check.

See:

• Error: unable to read metadata: go-import metadata not found #1406
• "source" declaration not followed? #860
• Support for private repositories e.g. Github Enterprise #174
• Support for private/enterprise patterns #286

I would like to be able to do the following work-around:

1. Manually create directories under vendor/ which are git submodules pointing to arbitrary git repositories. This allows whatever crazy hoops git needs to jump through to get the code in place completely transparent to dep ensure.
2. Specify unused-packages=false and other options for the appropriate prune in Gopkg.toml to make sure dep doesn't try to remove the git submodule directories I manually added to vendor
3. Specify the appropriate project roots in Gopkg.toml in noverify so that dep isn't required to pass any checks.

What version of dep are you using (dep version)?

$ dep version
dep:
 version     : v0.5.0
 build date  : 2018-07-26
 git hash    : 224a564
 go version  : go1.10.3
 go compiler : gc
 platform    : darwin/amd64
 features    : ImportDuringSolve=false

What dep command did you run?

dep ensure -vendor-only

What did you expect to see?

Warnings that indicate unable to read metadata: go-import metadata not found on the configured components, but as long as all affected paths are accounted in noverify, then dep ensure should complete with only printing warnings.

What did you see instead?

unable to read metadata: go-import metadata not found

and dep does not complete

[bhiggins]

Another corner case: we have a dependency that removed the ref that we were using. I was hoping that noverify might allow us to still use this ref but that didn't work.

[sdboyer]

GHE recently added support for responding to go get-style metadata requests - you might have better luck if you can update your instance.

Unfortunately, manual creation of directories under vendor is just never gonna be something dep can support. You're effectively asking for noverify to cause dep to treat the contents of vendor as canonical for the purposes of analyzing imports. That turns vendor into both a source of truth, and a target that we populate - an ouroboros. We just can't do that and maintain our basic guarantees.

The most that noverify can do is preserve what's in vendor.

[sdboyer]

@bhiggins that case is actually one that we designed for early on, but it fell by the wayside. It's possible it could be picked back up, but i'm not sure when 😢