Join GitHub today
x/website: outdated info about workspace and modules? #35919
The Getting Started page talks about setting up your workspace:
It links to the "Workspaces" section in How To Write Go Code, which explains a number of things:
Do they still do that today?
Is that still true?
These pages explain how to set up your workspace and
The Go 1.11 release notes stated:
That sounds great. Why isn't this the prescribed way to get started?
I found a useful introduction to go modules on this website, but (beyond the 1.11 announcement post) I haven't really seen modules mentioned or promoted anywhere on the official website.
With support for modules proper, it seems like this should be the preferred approach - the role of the global workspace should be reduced to global installations of tools and so forth, as is the case with most common package managers for other languages? (npm, etc.)
When the official documentation tells me that Go programmers "typically" keep all their Go code in a single workspace, that makes me feel insecure about even learning about modules.
Is a single, global workspace still the preferred/recommended approach?
Or why aren't you promoting the use of modules?
Thanks for reporting this.
Not completely true: There is a 4-parts series of posts about Go Modules on the project's website (first instalment: https://blog.golang.org/using-go-modules, with links to the other three).
Obviously the fact that you didn't know this suggests there's a "discoverability" issue somewhere.
Besides this, it's true that much of the documentation still needs to be updated to reflect changes in the way Go code is written after the introduction of modules.
Overall, the questions you raise here are valid, but the work needed to update the documentation is already being tracked in other issues (#33637 is the main one), so I think we can close this thread in favour of the older ones.
Online repositories including .deb and .rpm packages tend to use /usr/share/gocode as a directory to locate Golang sub-repositories, though these sometimes may place compiled executables outside of the Golang prescribed subdirectory structure for a Go path directory.
The value is unset, but a default is encoded in the go compiler.
($HOME/go on Unix, %USERPROFILE%\go on Windows, and $home/go on Plan 9)
To set on Unix-like a custom GOPATH, one can use shell builtins, export and setenv, respectively of bash and tcsh, entered in any of user customisation files, within an active shell session, or sourced via shell scripts.
If a Golang sub-repository is to be downloaded locally which depends on a sub-repository already installed globally note the ordering in the colon-separated string
The Windows NT kernel introduced multiple user-accounts and Vista added UAC, but I don't see for example C:\gocode being used for Golang sub-repositories to be installed globally.
As it stands on Plan 9 coders only use $home/go in their GOPATH.
Try also typing
Any resolution regarding (as I framed it) discouraging editing by non-contributors of certain wiki pages?
I noticed the Modules page has two edits this November.
We should do a pass through the installation instructions and any other new user docs and updating things for modules. Just a quick note on documentation in progress though:
I'm working on module reference documentation (#33637), which will be available at
The OP mentioned "Workspaces" and J. Conrad cites a code.html rewrite.
Maybe - though this is off topic - the following could be added (beneath the preceding quote).
Plan 9 configuration is usually done at the beginning of $home/lib/profile.
For PowerShell/PowerShell ISE add for example $Env:Path += ";~\go\bin" in the relevant file below.
NB: M. Klement's Gist (Out-FileUtf8NoBom.ps1) might be of interest.
Similar to @mindplay-dk's issue... except while his focus was on module locations and workflow, my issue is simply discontinuity or differences between pages under
These bumps are easy to work around if you know you can work in any directory.
IN "How to Write Go Code", it is not made clear why the module name
Coming from Python or another language, you would never see what appears to be a DNS FQDN in the package name - so the first viewing of this raises some interesting questions:
(Note: I am not using this space to ask these questions - please don't answer as such. I am pointing out that these were questions raised and unanswered, by reading "How to Write Go Code" )
(To clarify, I've already "answered" these questions to myself by plowing past them and using Google. How can we avoid leaving the reader with unanswered questions, when introducing new concepts? Also, if something I've said here is inaccurate or misleading, feel free to restate my question and answer)
@sprive Thanks for the feedback, this is helpful. Agree that How to Write Go Code should explain module paths and directories a bit more.
One thing to point out though: working in
This is a point of confusion for now because before Go 1.13, by default, module mode was never enabled within
cf: GH hosted repos for Go code
note the install location
obviously one would only run