To be honest, I think go mod vendor is a perfectly acceptable dependency review tool, and people already have dependency-review workflows oriented around it. (I would prefer that we keep it that way.)

CC @rasky @jayconrod @ianthehat

To be honest, I think go mod vendor is a perfectly acceptable dependency review tool, and people already have dependency-review workflows oriented around it

Quite agree for those people who use go mod vendor. But what about those people who don't?

Well, that would leave me with two questions:

1. What are the use-cases (if any) for which go mod vendor would be a poor enough fit to warrant creating (and maintaining) a separate tool?
2. Taking into account the various code-review tools already in use (for example, GitHub code reviews; Gerrit), what are the feasible alternatives to go mod vendor?

Well, that would leave me with two questions:

Those are indeed pertinent questions to which I don't have answers 😄, which is in large part the reason for me raising this issue. The UI/UX around this is not clear.

I see go mod vendor at one end of the spectrum of solutions here: dependencies committed along with code. At the other end of the spectrum (possibly) is some tool where dependencies get reviewed, "signed off" and served by a controlled proxy.

I guess I sit somewhere in between - I don't want my dependencies committed along with my code, but equally I'm not Big Corp enough to go all-out with my own proxy.

It's entirely possible that the tool I have in mind could use go mod vendor under the cover without committing vendor/ - I haven't really given it much thought.

@myitcv What is the current status of this idea? Thanks.

@ianlancetaylor apologies for the delay. There is really no further update to what's written above. There hasn't been any further discussion on this topic on golang-tools calls either. Might be worth closing for now therefore?