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

bcmills opened this issue Feb 15, 2019 · 1 comment

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

bcmills opened this issue Feb 15, 2019 · 1 comment


Copy link

@bcmills bcmills 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)

Copy link

@thepudds thepudds 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.

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants