Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
myitcv opened this issue Aug 5, 2019 · 4 comments
Open

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

myitcv opened this issue Aug 5, 2019 · 4 comments
Labels
Milestone

Comments

@myitcv
Copy link
Member

@myitcv myitcv commented Aug 5, 2019

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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Aug 6, 2019

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

This comment has been minimized.

Copy link
Member Author

@myitcv myitcv commented Aug 6, 2019

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?

@rsc rsc changed the title x/tools: proposal: dependency review tool proposal: x/tools: tool to audit diffs in dependencies Aug 6, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Aug 6, 2019

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

This comment has been minimized.

Copy link
Member Author

@myitcv myitcv commented Aug 12, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.