You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
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.
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?
The text was updated successfully, but these errors were encountered:
Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!
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 tototally.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 followingprojects
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
.Instead, this happens:
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?
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?
The text was updated successfully, but these errors were encountered: