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