Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

dep ensure -vendor-only does not work as expected #2106

Closed
RobvH opened this issue Feb 14, 2019 · 2 comments
Closed

dep ensure -vendor-only does not work as expected #2106

RobvH opened this issue Feb 14, 2019 · 2 comments

Comments

@RobvH
Copy link

RobvH commented Feb 14, 2019

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?

@kevinburke
Copy link
Collaborator

Thanks for the report. Do you have a public repo that can reproduce the problem you describe?

FWIW I would also recommend checking in the source folder if that's possible.

@mvdan
Copy link
Member

mvdan commented Sep 4, 2020

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!

@mvdan mvdan closed this as completed Sep 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants