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

meta: request output of `go list -m all` in the issue template #30256

Open
bcmills opened this issue Feb 15, 2019 · 1 comment

Comments

@bcmills
Copy link
Member

commented Feb 15, 2019

As @FiloSottile notes in #30241 (comment):

I actually don't want to have to figure out if a crypto/tls internal failure is due to a replaced chacha20poly1305.

But of course the same is true for x-repo interdependencies in general: if someone is reporting an issue against, say, x/tools or x/net, it would be really helpful to know the exact version in which they found the issue, and whether any of the dependencies involved have been locally modified.

I propose that we request go list -m all alongside go env in the issue template.

(CC @thepudds @myitcv @bradfitz)

@bcmills bcmills added this to the Unreleased milestone Feb 15, 2019

@thepudds

This comment has been minimized.

Copy link

commented Feb 15, 2019

This is probably good to do independent of the outcome of #30241.

Some people will want to remove proprietary or internal modules from the output of go list -m all, or substitute in foo or corp.example or similar. The template could attempt to briefly mention that is fine to do. Alternatively, could instead just wait to see if it confuses anyone in practice.

If you are not running with module mode enabled, go list -m all currently reports:

go list -m: not using modules

That is probably fine and understandable enough to not confuse people.

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