Can't init with generated sub-packages.

[slantview]

Tried to init repo, getting error. I have a package in vendor already that is generated (outside of git). dep doesn't seem to like that.

What version of Go (go version) and dep (git describe --tags) are you using?

go version
go version go1.9 darwin/amd64

dep version 0.3.0 (should make it easier to find this out.)

What dep command did you run?

dep init

dep init
^CNo versions of github.com/Juniper/contrail-go-api met constraints:
v1.1.0: Could not introduce github.com/Juniper/[email protected], as its subpackage github.com/Juniper/contrail-go-api/types is missing. (Package is required by (root).)
1.0.0: Could not introduce github.com/Juniper/[email protected], as its subpackage github.com/Juniper/contrail-go-api/types is missing. (Package is required by (root).)
master: Could not introduce github.com/Juniper/contrail-go-api@master, as its subpackage github.com/Juniper/contrail-go-api/types is missing. (Package is required by (root).)

What did you expect to see?

I expected to be able to initialize my vendor repo.

What did you see instead?

It just hangs. I expected it to timeout or something. Also it doesn't give me an error until I hit Ctl-c.

[sdboyer]

hi! ok so, couple things here. easy one first:

It just hangs. I expected it to timeout or something. Also it doesn't give me an error until I hit Ctl-c.

we're trying to improve feedback around this, but there's a lot of factors to weigh:

1. some of the cost is unavoidable, especially on larger projects - dep is cloning down a ton of repos for the first time. see the FAQ entry on this.
2. timeouts are difficult to guess at good values for; they work really poorly across different systems, different networks, etc. and, when one is hit, bailing out usually feels like the wrong thing to do. there are a buncha open issues related to this; e.g. Issue with cloudfoundry cli dependency #1034. that you didn't hit any timeouts is likely a product of a bunch of git clones running simultaneously, each making slow progress.

I have a package in vendor already that is generated (outside of git). dep doesn't seem to like that.

this is really the knottier problem. some quick background, first.

dep is built around an assumption that all generated code is being committed into dependency repositories. this was already at least a best practice around the time that go generate was released - i could've sworn the original blog post said as much, though i can't find it now. even then, elevating it to the level of requirement is another matter. enforcing package existence was one of calculated risks we took in our design, on the assumption that we'd get pretty swift and clear pushback if it turned out to be a problem.

in the past year or so (so, also including some time while we were looking at incorporating gps into glide), this has come up three times, IIRC. each time, no one's found it terribly objectionable that we have this "must commit generated code" requirement. the discussion has tended towards the idea that it's reasonable to expect having the package at least exist - see, for example, container-storage-interface/spec#91. so, i'd encourage that for this case as well - or, if there's a clear reason that that won't work, we can discuss that!

in any case, for right now, the more permanent fix is to ask github.com/Juniper/contrail-go-api to start either generating and committing the code in that dir, or at least committing a doc.go file to trick dep into thinking there's a package there.

in the meantime, your stopgap is a little painful, because you can't get past dep init, and we're still working on #909 to at least give you something incremental to work from. the only real way in now is to make a Gopkg.toml file containing github.com/Juniper/contrail-go-api/types in the ignored list, and then write in the rest of your constraints by hand 😢. (note that if that generated code has any unique imports, you'll also need to add those to the required list).

[sdboyer]

update: @jmank88 read the original blog post more closely, and here's the quote i was thinking of:

It's important to understand that go generate is not part of go build. It contains no dependency analysis and must be run explicitly before running go build. It is intended to be used by the author of the Go package, not its clients.