I looked around everywhere I could find, and I see two different interpretations of how the $GOPATH should work.
1.) The most common:
The $GOPATH provides us with a place to store common, shared third party libs on our system, and our own projects.
$GOPATH/src/ourcompany/ourproject1
$GOPATH/src/ourcompany/ourproject2
$GOPATH/src/othercompany/library1This structure works perfectly with go's build tools and saves us from having a new copy of each lib source per project.
2.) Also around
Every project directory gets added to the $GOPATH.
In project B, using lib X, which was previously installed in project A, we wouldn't see lib X in the src directory for project B, but as long as project A's directory is also in the $GOPATH, would all not work ok?
3.) Hybrid
We could add per-project directories to the $GOPATH, and also have a shared libs directory within the $GOPATH
Looking around dozens of major projects in the community, there is no consensus understanding on how this is supposed to work, and the docs don't quite clarify it. It says the $GOPATH is a workspace, but it doesn't say if that is intended as a per-project workspace.
This came up because the golang plugin for IntelliJ only works with pattern 2, and because it is not using the native import resolution tool (or $GOPATH), it breaks because it assumes that all code for a given project are within that precise project's directory. It thus requires a separate workspace per project, and the re-installation of third party libs within each project directory.
#1 is the correct and supported way. The other methods are actively discouraged.
Andrew
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Fantastic. Thank you. Might it be worth stating this more explicitly in the docs?
Actually, I think that part of the confusion comes directly from "How to write go code" (http://tip.golang.org/doc/code.html) .It refers to "Workspaces" (plural), which implies precisely the opposite of what Andrew Gerrand said above.Andrew Gerrand said that "#1 is the correct and supported way. The other methods are actively discouraged."
Just saying, it's not *entirely* obvious. At least, it wasn't to me.
Talking of the docs and the hierarchy of a workspace, does it have to be
specifically bin for executables? The pkg directory is structured
according to platform allowing a single workspace to be shared by many
platforms, but there appears to be only a single bin which is platform
specific.
It also seems that many packages install executables directly into
$GOBIN.
The single root also determines Go package names. As it happens, I've
been using a single root of D:\projects\<project> on my work computer
since long before learning about Go. But even this existing single
root organization is incompatible with GOPATH without adding an extra
src directory.
Are you suggesting the use of project paths like
D:\projects\src\someproject\src\package1? Seems like a mess,
especially since not everything under D:\projects\src\ is source code.
I don't really understand how you're organizing non-Go files.
My problem (if the goal is to avoid per-project entries in GOPATH)
with bin, pkg, and src is the order of the hierarchy. I want
project\bin, project\pkg, and project\src, in addition to
project\docs, project\media, and project\otherstuff. Incidentally,
look at how Go's own repository is organized. Do you have src/repo or
repo/src?
To be clear, I'm perfectly happy with GOPATH and bin, pkg, src
structure as a way of organizing small programs (mostly Go source code
in a single main package) and reusable libraries. I find it less
suitable for large applications consisting of many non-Go files and
multiple Go packages that are not intended for sharing.