Search code examples
gostructureorganizationtradeoff

Implications of not using repo path for my own packages

Suppose I decide to keep all personally developed packages organized as follows:

$GOPATH/
    bin/
    pkg/
    src/
        somepkg1
        somepkg2
        ...
        somepkgN

Further, suppose there is a great deal of code reuse among them, so I decide to keep the whole $GOPATH workspace under the same Git repository (each package could be a submodule), as opposed to more traditional scenario where subpackages are less coherent (co-existing solely because of using go get from the same workspace):

$GOPATH/
    bin/
    pkg/
    src/github.com/<me>/
        somepkg1
        somepkg2
        ...
        somepkgN

I can see that with the former approach (not using github.com/<me>/ in the package paths), go get would not be able to fetch packages as they are not "declaring" themselves to be available online. However, one can easily work around that by using git submodules, so all packages would be fetched in the first place (note it's a tightly controlled ecosystem so there will be no name clashes).

Is there any other limitation (besides go get) of not using full paths for packages?

(I am mostly concerned about limitations arising from certain code refactoring/analysis tools that exploit the repository path as base path convention that allows go get to look for the package online.)

Solution

  • For the Go compiler and all elements of the go tool except go get the package import path is an almost opaque string containing the import path. You can lay out your code like you want (the compiler itself happy compiles files from different folders into one package). If you don't need or want your code to be go getable there is no need to use a repo path. The analysis and refactoring tools in golang.org/x/tools work on the opaque import paths (as far as I know) and do not access the network.