Skip to content
This repository was archived by the owner on Sep 9, 2020. It is now read-only.
This repository was 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

Description

@RobvH

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions