Join GitHub today
website: Update "How to Write Go Code" with go modules #28215
referenced this issue
Oct 15, 2018
@andybons @bcmills This might be somewhat stuck with some type of CLA-related issue? See for example #28218 (comment). Is there someone you could suggest who could help unstick the CLA issue? Or is there some other approach you might recommend like deleting the PR and trying again in the hopes of avoiding whatever tripped up the CLA bot?
referenced this issue
Dec 23, 2018
Several months ago, I think the plan or hope was that GO111MODULE would default to
It now seems for multiple reasons GO111MODULE will still default to
Reading through the comments in this issue and the PR and CL, I initially thought your intent was to update "How to Write Go Code" to be a modules-specific document, and to drop the details of older GOPATH behavior... but now after reading through more of the CL, I am not sure if that was the intent?
My personal take is:
Together, that might seem to imply there could be two versions of this document – a new version that is modules-specific, and one that is the current GOPATH-specific version.
However, I am not sure of the best approach, so more than anything I wanted to ask what you might be currently thinking...
Finally, note that I'm basically just a random member of the community, so please do not give too much weight to anything I say here or in the CL (and instead just view my comments as coming from a peer in the community).
Generally, documentation fixes are permitted during the freeze so it’s feasible this will get in by the time 1.12 stable is released. No need to worry about that.
Let’s wait for @bcmills to respond. Many people are out this week for the holidays so we’ll need to be a bit patient. Thanks.
@andybons Do you know if there is still time for this to land in time for 1.12?
Also, there is some nuance here. This is not a complete list of open questions, but for example:
There is a longer list of questions, and I'm not suggesting all open questions be answered immediately. Rather, I am listing those example questions primarily to suggest there is a healthy chance that ultimately more than one person on the core Go team might want to weigh in on this effort.
In general, there is a natural cadence to open source development that often involves waiting (e.g., waiting for someone to have something initially ready for feedback, waiting for it to get to the top of a reviewer's stack, waiting to find time to incorporate latest feedback, etc.), and patience is certainly a virtue in all of this...
...but I also wonder:
Or if not exactly something like that, then perhaps some other small amount of orchestration that could help increase the odds of this landing in time for 1.12?
There is realistically no way this will land for 1.12, but we should make sure it is updated for 1.13.
I think that discussion of
I would rather see