dep ensure -vendor-only does not work as expected #2106
Description
When using dep ensure -vendor-only
I expect that the Gopkg.toml will not be parsed and that the vendor folder will be built entirely using the Gopkg.lock; especially using the source="" keys strictly to determine sources.
The problem (relates to #860 but that's grown long and unfocused, and hasn't been fixed for 1+ years), is that we have some dependencies (both direct and nested) that are in a repo that is not and cannot be available to our CI pipeline. Thus I've mirrored those repos into GitHub in a location that is accessible. This should be easy, but bugs in dep are blocking. There seem to be two issues:
1 - dep ensure -add totally.private.intranet.repo/amazing/package:github.com/accessible/amazing/package
should just work and should NOT attempt to read nor connect to totally.private.intranet.repo/amazing/package
but it does.
2 - dep ensure -vendor-only
should just trust the Gopkg.lock file and install using the source keys when specified. So, in the case of the following projects
block in the Gopkg.lock, dep should not attempt to connect to "name" and should only read from source. It shouldn't care about the Gopkg.toml, since after all we're using -vendor-only
.
[[projects]]
branch = "master"
digest = "1:..."
name = "totally.private.intranet.repo/amazing/package"
packages = [
"thing1",
"thing2",
"thing3",
]
pruneopts = "UT"
revision = "completely valid commit hash"
source = "https://github.com/accessible/amazing/package"
Instead, this happens:
dep ensure -vendor-only
The following issues were found in Gopkg.toml:
✗ unable to deduce repository and source type for "totally.private.intranet.repo/amazing/package": unable to read metadata: unable to fetch raw metadata: failed HTTP request to URL "http://totally.private.intranet.repo/amazing/package?go-get=1": Get http://totally.private.intranet.repo/amazing/package?go-get=1: dial tcp: lookup totally.private.intranet.repo on 127.0.0.11:53: no such host
ProjectRoot name validation failed
Of course the host in inaccessible, isn't that the point of using an alternate location?? Why is a -vendor-only
install even reading the .toml? Why is it trying contact the named package instead of the source?
Is it possible dep is trying to be a little too smart and making bad assumptions?
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
Help resolving this would be greatly appreciated. We really need a fix on this and I see lots of folks seem to be affected (referencing the stale, #860).
Other than dropping dep and checking in the whole source folder, what option do we have?