3 ms·

This all makes a lot of sense for non-main packages. I am curious though what people are doing with their main packages and their non-code dependencies. Say you

by james4k 14y ago

This all makes a lot of sense for non-main packages. I am curious though what people are doing with their main packages and their non-code dependencies. Say you were writing a web app in Go, or some other executable. Is the convention to put main packages in src/cmd/somename? And is there any convention for the location of related files such as templates, configs, etc.? What I've been doing recently is keep web apps in separate gopaths, and having code in src/ like usual (with src/cmd/frontend as an example, then a 'go install' outputs to bin/frontend), and then relevant dirs to the app: config/, templates/, etc. all in the root of the gopath, much like a typical project directory tree I suppose. However, I get the impression this is not the 'right' way to do it.

enneff 14y ago
You should put your entire project under $GOPATH/src/path/to/project, including non-code dependencies and main packages.
- duaneb 14y ago
  This annoys me immensely. I understand a standardized format for installed packages, but I should be able to dictate the hierarchy of my own code....
  - deleted 14y ago
    [deleted]
  - genbattle 14y ago
    If everyone dictated their own hierarchy for their code base, utilities like go build and go get wouldn't work. The guidelines are just guidelines - you can still do whatever the hell you want, but don't expect the standard tools to automatically handle all your own personal preferences for project structure. Go had has this structure ever since the Go 1 release - your source goes in $GOPATH/src/$YOUR_PATH, and the go get/build tool will compile any main packages to $GOPATH/cmd, and all packages to $GOPATH/pkg/$YOUR_PATH. If you really want to isolate the code for a specific application/project, why not use a folder structure like $GOPATH/src/$PROJECT/$PACKAGE or $GOPATH/src/$PROJECT/$EXECUTABLE. I had problems initially adjusting to the Go 1 workspace changes, but it's really not a big issue once you adapt a little (like anything in Go).
  - johnpmayer 14y ago
    $GOPATH is like $PATH in that it is a list of colon delimited directories, so it more like ${ANYNUMBEROFPLACES}/src/packages

by james4k 14y ago

enneff 14y ago

You should put your entire project under $GOPATH/src/path/to/project, including non-code dependencies and main packages.

duaneb 14y ago
This annoys me immensely. I understand a standardized format for installed packages, but I should be able to dictate the hierarchy of my own code....
- deleted 14y ago
  [deleted]
- genbattle 14y ago
  If everyone dictated their own hierarchy for their code base, utilities like go build and go get wouldn't work. The guidelines are just guidelines - you can still do whatever the hell you want, but don't expect the standard tools to automatically handle all your own personal preferences for project structure. Go had has this structure ever since the Go 1 release - your source goes in $GOPATH/src/$YOUR_PATH, and the go get/build tool will compile any main packages to $GOPATH/cmd, and all packages to $GOPATH/pkg/$YOUR_PATH. If you really want to isolate the code for a specific application/project, why not use a folder structure like $GOPATH/src/$PROJECT/$PACKAGE or $GOPATH/src/$PROJECT/$EXECUTABLE. I had problems initially adjusting to the Go 1 workspace changes, but it's really not a big issue once you adapt a little (like anything in Go).
- johnpmayer 14y ago
  $GOPATH is like $PATH in that it is a list of colon delimited directories, so it more like ${ANYNUMBEROFPLACES}/src/packages