dep ensure produces incomplete vendor results #1890
Comments
|
Getting the same issue when I run I checked the |
|
Thanks for your patience with slow responses here - i've been quite consumed with #1912. Nearly done with that, though, and release coming this week! So the simplest explanation here is that, somehow, dep is pruning something it shouldn't. Step one for that would be adding this in [prune]
# (whatever your current global prune settings are)
[[prune.project]]
name = "github.com/docker/docker"
unused-packages = falseThat, at least, should make sure all of docker is there. However, none of this should be necessary; dep is only pruning out packages that are not a part of the package graph you actually use, directly or transitively. If that's not the case, something's really wrong (and this would be the first instance of it happening). Without those pruning options on, what are the actual compile errors you're seeing that lead you to believe you're missing necessary code? Also - any chance there are submodules involved? If so, #1909 could be the culprit. Barring pruning issues (which also don't really make sense, per the above), that's my best immediate guess about missing files. |
|
thanks for your response. no worries about the delay. I made do in the meantime with some ad hoc git checkouts. using I am not using submodules in my respository. doesn't appear that docker/docker is using submodules either. I'm not sure if this issue is a dup so I'll leave it to you to remain open or to close it. thanks for all your efforts! much appreciated! |
|
I'm glad it helped! but, this is actually a big concern - could you tell me what compilation errors you were getting prior to changing the pruning options? |
|
@sdboyer oh, for sure! let me pull the compilation errors for you. What version of
|
|
@syphoxy ohhh, ok - i tried those imports, and it looks like it's something else: dep was picking an older tagged release of It's very odd that changing the pruning options would affect outcomes in this way, as there's no way those options can changing solving/version selection behavior, and the only way i can imagine the compilation errors going away is if versions changed. Any chance you could expand this to more precise reproduction steps? And/or, could you have a look at the |
|
I have the same issue with package main
import (
"fmt"
"github.com/satori/go.uuid"
)
func main() {
fmt.Println(uuid.Must(uuid.NewV4()).String())
}dep version: |
|
@sdboyer strong observation you've made. it is true that I had to add an it appears that when I leave the constraint override in and remove the this is the final does this mean the issue is entirely on |
|
@syphoxy sorta on them, yeah. There's some more we could do to get it right - and those things are going to become front-and-center for me after i roll this new release this week. But, basically, yeah, it's not great that there are tagged releases of docker that effectively rely on certain branch positions of its dependencies. 😢 @mohammed90 that's really weird. i can't replicate it locally - i get [testuuid] ls -la vendor/github.com/satori/go.uuid
total 80
drwxr-xr-x 9 sdboyer staff 306 Jul 11 02:13 .
drwxr-xr-x 3 sdboyer staff 102 Jul 11 02:13 ..
-rw-r--r-- 1 sdboyer staff 377 Jul 11 02:13 .travis.yml
-rw-r--r-- 1 sdboyer staff 1082 Jul 11 02:13 LICENSE
-rw-r--r-- 1 sdboyer staff 1885 Jul 11 02:13 README.md
-rw-r--r-- 1 sdboyer staff 6029 Jul 11 02:13 codec.go
-rw-r--r-- 1 sdboyer staff 6003 Jul 11 02:13 generator.go
-rw-r--r-- 1 sdboyer staff 2382 Jul 11 02:13 sql.go
-rw-r--r-- 1 sdboyer staff 4184 Jul 11 02:13 uuid.goAny further suggestions on how i might reproduce it? |
|
Hmm. With no constraints specified, it pulls [[override]]
name = "github.com/satori/go.uuid"
revision = "v1.2.0" |
|
OK, so that suggests that there's no structural problem here with writing out vendor - only the known issues with UX. gonna close this one out. |
|
For someone facing with this horrendous issue. The following helped because I wanted to use docker client with wait for container to launch and stuff: |
|
As someone brand new to Go and trying to use the Docker API, finding this was a huge relief. Thank you to everyone here, I can't imagine how much frustration you just saved me. |
I believe this explains itself. my code won't compile if I use dep as my vendor appears to be missing source files. I've checked that the missing directories do actually contain
.gofiles.this is how I check out a working vendor dependency:
this is what I have in
Gopkg.toml:I've verified using
api/common.gothat in both instances the code is checked out from the correct revision. it appears that dep simply just didn't get some.gofiles.for example, common.go has no differences:
I've also used
go ensure -vto see additional output but unfortunately the output does not detail exactly what occurred here.any help would be appreciated. thank you.
also: I realize that constraining to a revision is an anti-pattern but unfortunately docker/moby upstream developers have failed to properly add a tag for the API version I need to use in my software. please don't remind me.
What version of
depare you using (dep version)?What
depcommand did you run?dep ensureWhat did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: