Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: The modules feature acts in surprising ways #34025
I was trying to use
Following that I tried to run a few commands and noticed many internet requests and re-downloads of packages it already had (
This led me to look into the many opened issues against go modules and the list is fairly expansive. I can be quoted as saying I will not move my open source libraries to Go modules until the feature has worked out the major kinks and I'm sad to report I still have not been able to move them. I think mostly the amount of surprise and inconsistency generated by the go command in module mode is the main problem. This is very unlike the rest of my Go experience, especially my experience with using the Go command ever since 1.0. It's been consistent, unsurprising, fast and generally an excellent tool. It does exactly what I tell it and expect in all circumstances until modules came along.
The go command has become surprising, inconsistent and sometimes slow when people run it in module mode. Commands that seem to be obvious introspection only commands (like
So why create this issue? I want to highlight the inconsistency and surprise, attempt to get the developers to think of it as a systemic problem and not just a bug here or there. We need some overall rules about how the go command should work, what sub-commands are blessed with the ability to reach out to the internet and download source, and which should NEVER attempt to do this (as an aside
Mostly, it is an attempt to have people re-evaluate the Go command in module mode from a user perspective, and see how the current implementation of modules inside it seems to be violating the principle of least surprise at the very least. Is there a version of the Go command that could be a better user experience? I just want to ask the question. Is it possible to step back and take a look at how it's working today and find a better way? Or are we stuck with the decisions we've made because of technical reasons (a requirement on full module graph resolution for every command which requires downloading of zips with go.mods in them)?
Read-only expected, but modify/talk to internet
Many commands (
Lack of good introspection
There's not much actionable on this issue as it's more of a meta issue, I would hope a few of the developers read it before closing it and maybe have a hard think about how the Go tool is behaving these days (v1.12-v1.13) and if it's a desirable state.
On the positive side: I really appreciate the Go team's efforts on the module feature. In general I believe the design behind MVS, the Proxy/Sum/Index are all great and appear to work well (had the git.apache.org/thrift missing issue resolved by using proxy.golang.org as a stop-gap last night and I thought it was really great it worked exactly as intended to prevent disappearing packages (I realize their import path has changed)). Cheers to the Go team and other contributors for all the hard work so far.
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
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
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
In my personal experience,
That said, perhaps this could suggest that maybe the default behavior of
@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 :)