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 · 6 comments
Open

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

myitcv opened this issue Aug 5, 2019 · 6 comments

Comments

@myitcv
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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.

@ianlancetaylor
Copy link
Contributor

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

@myitcv
Copy link
Member Author

myitcv commented Mar 1, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Incoming
Development

No branches or pull requests

4 participants