¿Es una mala idea tener el código fuente para un proyecto Go fuera de GOPATH?

Estoy trabajando en un nuevo proyecto con Go, y todos somos nuevos en Go. Estamos siguiendo la estructura estándar del directorio go, y tenemos todo el código bajo

$ GOPATH / src / github.com / companyname / projectname

que también es la raíz de un repositorio git

El diseño de ruta recomendado estándar parece un poco extraño, especialmente si estamos trabajando en un proyecto en varios idiomas, por ejemplo, un servidor basado en Go rest / http y un front-end html / javascript. En ese caso, probablemente querría que la estructura de mi proyecto se vea así:

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

Pero, ¿es realmente necesario tener el código colocado dentro de GOPATH?

Como intento, creé un pequeño programa donde el código fuente estaba fuera de GOPATH. Podría dividir fácilmente el proyecto en paquetes, por lo que el mainpaquete podría hacer referencia a un foopaquete en una foo/carpeta usando import "./foo".

Hasta donde puedo ver, hay dos cosas que esto no me permite:

• Otro código no puede importar este código. Esto no es un problema ya que estamos construyendo un servicio específicamente para la empresa.
• No puedo usar go installpara instalarlo. Esto tampoco es un problema. La tubería de compilación instala la herramienta.

Sin embargo, permite que el servidor de compilación no tenga su espacio de trabajo ubicado dentro de GOPATH

¿Se desalienta este enfoque? Si es así, ¿por qué?

¿Hay otros efectos secundarios negativos que los dos que he enumerado?

Tenga en cuenta que este es un proyecto privado para una empresa, no un código público de código abierto.

Separar el proyecto real del GOPATH parece tentador, pero hay que tener cuidado al romper las reglas cuando estás en el escenario de Shu

No es necesario que use GOPATH, pero luego se pierde todas las herramientas útiles que obtiene del gocomando. Todos esperan que el código esté en la jerarquía GOPATH estándar.

Usted mencionó go install, pero también go test(y la buena go test -coverherramienta de cobertura) no funcionará go get, lo que le permite descargar el código remoto y escribirá todo en GOPATH, por lo que deberá copiar las cosas.

Claro, puede reemplazarlo todo con make / scons / cmake / whatever y hacer las cosas y probablemente funcionará para su entorno, pero es un trabajo adicional que podría hacer la goherramienta.

(descargo de responsabilidad: me gusta diseñar cosas como esta, pero soy nuevo en Go, no lo he probado en la práctica)

Idea: ¿Por qué no ambos?

Hay dos opciones polares disponibles si tiene en cuenta los enlaces simbólicos:

(A) Código en src, enlace simbólico al espacio de trabajo

/
  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 en el espacio de trabajo, enlace simbólico 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

Me inclinaría hacia "A" porque:

• todas tus fuentes viven físicamente juntas,
• projectname puede tener fácilmente su propio repositorio, o puede tener un repositorio para todo su proyecto,
• puedes mantener todo sin go_workspaceversionar e inicializarlo a través de un paso de godepcreación (usando luego simultaneando el proyecto)

Actualización 2019

Ya no necesita almacenar su proyecto debajo GOPATH.

Póngalo en un directorio fuera de GOPATH. Luego escriba:

go mod init github.com/youruser/yourproject

Estarás listo para ir.