CC @bcmills @jayconrod

Thanks for the thoughtful feedback, but as you note, there isn't much actionable on this issue.

Nearly every point of confusion that you've raised already has an issue filed, and as we resolve each of those issues we are certainly doing our best to “step back and take a look […] and find a better way” to improve consistency and comprehensibility overall.

@bcmills I think that there's been an unwillingness in the issues to consider a big change to the way it functions given the responses on the issues I've highlighted so it sounds like as an example many operations will continue to write to the disk and connect to the internet when they should perhaps not.

Have we thought about making these commands error out citing insufficient data? Have we thought about going more bundler/cargo/npm route with a dedicated "get stuff from the internet" vs all this automatic resolution at any cost (downloading source zip files to do go list)? These are the types of big design questions I was hoping this issue would help people start thinking about. Like I said it's a systematic problem throughout the tool, as each subcommand gains more and more power and less and less does one thing and does it well. As an example: go fmt talks to the internet... I mean surely you see that as being a big problem, no? I think the reason it comes up over and over again (there are many duplicates) is because it's surprising and undesirable behavior from a user's perspective.

Although this specific issue has no actions to carry out, your response is underwhelming and to hand-wave it away with "there are issues for all the issues you pointed out" is the exact problem I was trying to highlight: if we look at each of these in isolation it doesn't prompt big design changes, it makes them all look like individual issues but they're not, they're all part of a larger whole. If any of the responses in the issues hinted at "maybe we need some changes to the way this works" then I never would have created this issue in the first place. Had your response included hints that these sorts of "big picture" design/implementations have been carefully thought out and re-thought in the face of all these issues I never would have even replied to this issue's closing. But in the absence of all of that I felt compelled to reply once as a last ditch attempt. I hope that if not the issue itself, this response prompts the reconsideration of the design at large as I was hoping for even if the outcome is "this is the way we want it to be". Thanks for at least taking the time to read and reply, and again all your work on the project.

Edit: took out some of the passionate fire, apologies

Have we thought about making these commands error out citing insufficient data?

Yes. We have thought about it many times in the past (see the lengthy discussion on #27643), and are continuing to think about it (for example, in #32027, which you've already cited).

Have we thought about going more bundler/cargo/npm route with a dedicated "get stuff from the internet" vs all this automatic resolution at any cost (downloading source zip files to do go list)?

Yes, we are continuing to think about that as part of #29452.

It is not a matter of not having considered the alternatives, or of having rejected the alternatives. There are open issues for these things because they remain unresolved, and an appropriate resolution necessarily requires us to consider both small/tactical and large/strategic changes.

@aarondl FWIW, I also thought this was very thoughtful feedback.

You made many points, but I am only making two very narrow comments here:

1. You might want to consider linking to this issue from the "Experience Reports" wiki page. That can help other people find your commentary, and Experience Reports I think are one way the Go team is trying to organize broader feedback that not might be a specific bug report or specific feature change. See the top of the wiki page for a bit more details, and they have also been discussed in some of the GopherCon keynotes if you are interested in more of the philosophy behind asking the broader community to provide them.

2. If you are not already, you might want to try doing go mod why -m foo (note the -m), rather than or in addition to go mod why foo (without the -m). The -m indicates the argument is a module path, which usually casts a broader net and hence more often comes back with an answer. (Also, people are often doing go mod why in response to an error message, where module-related error messages often include module paths and hence makes sense to from a module path in an error message to go mod why -m with the -m).

In my personal experience, -m vs. no -m is more often the explanation for a main module does not need foo response from go mod why, and more rarely is that response due to something that is arguably a bug or missing feature like #27900.

That said, perhaps this could suggest that maybe the default behavior of go mod why should change, so that the default is a module path, or so that it suggests re-running with -m if no results, or some other tweak that helps people get an answer more frequently.

@thepudds Thank you for the feedback. I'm not sure it qualifies as a -real- experience report. It's missing a bit of detail that I'd expect from one, and I'd obviously be a bit too biased to correctly judge whether or not it should be included. I'll leave it to others to make the decision :)

As for go mod why -m vs no -m although I never state it I basically always include the -m because I'm generally looking for why modules in go.mod are imported. Whenever it doesn't turn up something I want I try the package version (omitting the -m). Even so, thanks for the tip, if I had missed that it would have been quite helpful. I don't disagree with changing it's behavior (why is it called go mod why when it operates on packages by default?). Perhaps we should create a new issue for that?