Add minimal version of golang/protobuf in dep config for Go

[qneyrat]

Fix version of golang/protobuf because can use older version.

Example: proto.InternalMessageInfo isn't declare in golang/protobuf 1.0.0

[beorn7]

Thanks for the PR.

The problem here is that we already had many back-and-forth iterations adding and removing vendoring in libraries. Last time we discussed this, my impression was that the Go community strongly discourages vendoring in libraries. I would like to see firm evidence that this has changed before adding vendored dependencies once more. Do you know of anything like that?

[qneyrat]

Dep vendor dir of lib is never import in final app.
I remove vendor dir but constraint is very important

[qneyrat]

maybe it's important to fix dependencies versions in prometheus/client_golang

[beorn7]

maybe it's important to fix dependencies versions in prometheus/client_golang

I'm not sure what you mean by that. client_golang is a library, too, so we don't vendor there, either. (We in fact did, and then removed it again after much discussion.)

About the Gopkg.toml file: IIRC, that's specific to the dep tool. AFAIK, that's not (yet) the tool the Go community has converged on (and if I read recent news, it never will be because Go 1.11 has that modules thing). I might be totally mistaken. Happy to gain better insight. But right now, I don't see how dropping a spec file from one specific dependency management tool in this repo will help more than it will cause confusion.

I would also like to understand the problem better. If I just do a go get with a plain state of my repo, everything should work, shouldn't it? Only if somebody for some reason has kept an older version of golang/protobuf around, they will run into issues. But that's potentially true for every single dependency. As long as Go dependency management isn't solved in a commonly adopted form, what can we do?

[beorn7]

I interpret the silence as "there is indeed nothing we can do right now until there is a commonly adopted solution to dependency management in Go". I'll close this now, but feel free to follow up later.