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?

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

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

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?

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.