É ruim ter código-fonte para um projeto Go fora do GOPATH

Estou trabalhando em um novo projeto usando o Go, e somos todos novos no Go. Estamos seguindo a estrutura de diretórios padrão go e com todo o código em

$ GOPATH / src / github.com / nome da empresa / nome do projeto

que também é a raiz de um repositório git

O layout padrão do caminho recomendado parece um pouco estranho, especialmente se estivermos trabalhando em um projeto em vários idiomas, por exemplo, um descanso / http back-end baseado em Go e um front-end html / javascript. Nesse caso, eu provavelmente gostaria que minha estrutura de projeto fosse assim:

/
  doc/
  src/
    server/
      main.go
      module1/
        module.go
    client/
      index.html
  Makefile

Mas é realmente necessário colocar o código dentro do GOPATH?

Como tentativa, criei um pequeno programa em que o código fonte estava fora do GOPATH. Eu poderia facilmente dividir o projeto em pacotes, para que o mainpacote pudesse fazer referência a um foopacote em uma foo/pasta usando import "./foo".

Tanto quanto posso ver, há duas coisas que isso não me permite:

• Outro código não pode importar esse código. Isso não é um problema, pois estamos construindo um serviço especificamente para a empresa.
• Não consigo usar go installpara instalá-lo. Isso também não é um problema. O pipeline de construção instala a ferramenta.

No entanto, permite que o servidor de construção não tenha seu espaço de trabalho localizado dentro do GOPATH

Essa abordagem é desencorajada? Se sim, por que?

Existem outros efeitos colaterais negativos além dos dois que listei?

Lembre-se de que este é um projeto privado para uma empresa, não um código-fonte aberto público.

Separar o projeto real do GOPATH parece tentador, mas é preciso ter cuidado ao quebrar as regras quando você está no palco Shu

Você não precisa usar o GOPATH, mas perde todas as ferramentas agradáveis ​​que obtém do gocomando. Todos esperam que o código esteja na hierarquia padrão do GOPATH.

Você mencionou go install, mas também go test(e a boa go test -coverferramenta de cobertura) não funcionará go get, o que permite que você baixe o código remoto gravará tudo no GOPATH, portanto será necessário copiar as coisas.

Claro, você pode substituir tudo por make / scons / cmake / Whatever e fazer as coisas, e provavelmente funcionará para o seu ambiente, mas é um trabalho extra que pode ser feito pela goferramenta.

(aviso: gosto de criar coisas como esta, mas sou novo no Go, não tentei na prática)

Idéia: Por que não os dois?

Existem duas opções polares disponíveis se você considerar o link simbólico:

(A) Código no src, vinculado à área de trabalho

/
  doc/
  src/
    server/
      projectname/
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname -> ../../../src/server/projectname
      github.com/
        someone/
          library/
    bin/
    pkg/
  Makefile

(B) Código no espaço de trabalho, vinculado a src

/
  doc/
  src/
    server/
      projectname -> ../../go_workspace/src/companyname/projectname
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname/
      github.com/
        someone/
          somelib/
    bin/
    pkg/
  Makefile

Eu me inclinaria para "A" porque:

• todas as suas fontes vivem juntas fisicamente,
• projectname pode facilmente ter seu próprio repositório ou você pode ter um repositório para todo o projeto,
• você pode manter todo go_workspacenão-versionado e inicializá-lo através de uma etapa de criação (usando o godeplink simbólico do projeto)

Atualização de 2019

Você não precisa mais armazenar seu projeto GOPATH.

Basta colocá-lo em qualquer diretório fora de GOPATH. Então digite:

go mod init github.com/youruser/yourproject

Você estará pronto para ir.