go-chrome icon indicating copy to clipboard operation
go-chrome copied to clipboard

Dep Build Fails

Open adamgoose opened this issue 6 years ago • 6 comments

What version of go-chrome are you using (tag, hash, etc.)?

[[constraint]]
  name = "github.com/99designs/gqlgen"
  version = "0.4.4"

[[constraint]]
  name = "github.com/gorilla/mux"
  version = "1.6.2"

[[constraint]]
  name = "github.com/vektah/gqlgen"
  version = "0.4.4"

[[constraint]]
  branch = "master"
  name = "github.com/vektah/gqlparser"

[[constraint]]
  branch = "develop"
  name = "gitlab.internal.bcx.zone/bcx-go/bcx5"

[prune]
  go-tests = true
  unused-packages = true

[[constraint]]
  name = "github.com/mkenney/go-chrome"
  version = "1.0.0-rc4"

What behavior do you expect? What are you trying to accomplish?

go build works

What behavior are you experiencing instead?

% go run main.go
# gitlab.internal.bcx.zone/bcx-pisoft/display-daemon/vendor/github.com/mkenney/go-chrome/tot/socket
vendor/github.com/mkenney/go-chrome/tot/socket/socket.conner.go:82:13: invalid argument socket.listenErr (type "gitlab.internal.bcx.zone/bcx-pisoft/display-daemon/vendor/github.com/bdlm/errors".Err) for len
vendor/github.com/mkenney/go-chrome/tot/socket/socket.socketer.go:259:24: cannot call pointer method on err.("gitlab.internal.bcx.zone/bcx-pisoft/display-daemon/vendor/github.com/bdlm/errors".Err)
vendor/github.com/mkenney/go-chrome/tot/socket/socket.socketer.go:259:24: cannot take the address of err.("gitlab.internal.bcx.zone/bcx-pisoft/display-daemon/vendor/github.com/bdlm/errors".Err)
vendor/github.com/mkenney/go-chrome/tot/socket/socket.socketer.go:483:13: invalid argument socket.listenErr (type "gitlab.internal.bcx.zone/bcx-pisoft/display-daemon/vendor/github.com/bdlm/errors".Err) for len

adamgoose avatar Sep 14 '18 22:09 adamgoose

it seems like your dep ensure didn't respect the Gopkg.lock file included in the repo somehow. v1.0.0-rc4 has the github.com/bdlm/errors commit 4261cfedec68315454b163ae305cd34ecfc8b059 pinned but your error output is using a later version of that package.

You could try deleting vendor/github.com/mkenney/go-chrome and vendor/github.com/bdlm/errors, and then running dep ensure again. In vendor/github.com/bdlm/errors/err.go, line 15 should read

type Err []ErrMsg

and not

type Err struct {
    errs []ErrMsg
    mux  *sync.Mutex
}

Let me know how that goes.

mkenney avatar Sep 14 '18 23:09 mkenney

I trashed the entire vendor dir and Gopkg.lock, re-ran dep ensure, and still get the same thing. Trying some other things...

adamgoose avatar Sep 15 '18 02:09 adamgoose

Sounds like this dep caveat suggests you need to update your Gopkg.toml file.

Adding this to my Gopkg.toml has resolved this issue.

[[override]]
  name = "github.com/bdlm/errors"
  version = "=0.1.0"

[[override]]
  name = "github.com/bdlm/log"
  version = "=0.1.0"

adamgoose avatar Sep 15 '18 02:09 adamgoose

Ahh, I see! I was under the impression that dep respected package lockfiles when determining transitive dependencies, I will keep that in mind.

I haven't really been keeping up to date on the dependency management ecosystem for a while, but dep can be frustrating for other reasons too. I'll start exploring what the options are these days, maybe there's something better. After go v1.11 has been out a while longer I may just drop support for 1.9 and 1.10 and use modules instead.... I don't know how much of a pita that might be for people though.

I have pinned the correct versions of those packages in the v1.0.0-rc5 release. Please let me know if that solves the issue for you. Thank you for bringing this to my attention!

mkenney avatar Sep 15 '18 18:09 mkenney

I just got bitten by this too when I rebuilt my containers 😃

I haven't been using go dep as I'm too lazy to learn/rewrite my builds and have just been go geting all my packages...

I'm now just using my fork of your github.com/bdlm/errors and reverted to v0.1.1 to get around this for now (I'm sure there's better ways!).

I know that go get doesn't allow you to target a specific commit/tag/branch which makes things difficult - especially w/ a fast-moving package such as this -- so I too am hoping for a better way and maybe "go modules" is the answer. 👍

ozburo avatar Sep 18 '18 11:09 ozburo

I'm excited to play with them. This package will probably be my first stab at it.

mkenney avatar Sep 18 '18 23:09 mkenney