proposal: x/tools: tool to audit diffs in dependencies

[myitcv]

One of the key points from #30240 is:

Saved module caches do not interoperate well with version-control and code-review tools.

This point is further developed in #30240 (comment).

Raising this issue as a placeholder for the discussion about this specific point, because this point has a life well beyond and decisions on vendor and is relevant (by and large) to all users of Go.

Please add to/edit this description as required - this is just a placeholder

[bcmills]

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

[myitcv]

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?

[bcmills]

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?

[myitcv]

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.

[ianlancetaylor]

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

[myitcv]

@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?