Avere il codice sorgente per un progetto Go al di fuori di GOPATH è una cattiva idea

Sto lavorando a un nuovo progetto utilizzando Go e siamo tutti nuovi su Go. Stiamo seguendo la struttura di directory go standard e disponiamo di tutto il codice

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

che è anche la radice di un repository git

Il layout del percorso consigliato standard sembra un po 'strano, specialmente se stiamo lavorando a un progetto multilingue, ad esempio un back-end rest / http basato su Go e un front-end html / javascript. In tal caso, probabilmente vorrei che la struttura del mio progetto fosse simile a questa:

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

Ma è davvero necessario avere il codice inserito all'interno del GOPATH?

Come tentativo ho creato un piccolo programma in cui il codice sorgente era al di fuori di GOPATH. Potrei facilmente dividere il progetto in pacchetti, quindi il mainpacchetto potrebbe fare riferimento a un foopacchetto in una foo/cartella usando import "./foo".

Per quanto posso vedere, ci sono due cose che non mi permettono:

• Altro codice non può importare questo codice. Questo non è un problema in quanto stiamo costruendo un servizio specifico per l'azienda.
• Non posso usare go installper installarlo. Anche questo non è un problema. La pipeline di build installa lo strumento.

Tuttavia, consente al server di compilazione di non trovare il proprio spazio di lavoro all'interno di GOPATH

Un tale approccio è scoraggiato? Se è così, perché è così?

Ci sono altri effetti collaterali negativi rispetto ai due che ho elencato?

Tieni presente che questo è un progetto privato per un'azienda, non un codice pubblico open source.

Staccare il progetto reale dal GOPATH sembra allettante, ma bisogna stare attenti a infrangere le regole quando si è sul palco di Shu

Non ti viene richiesto di usare GOPATH, ma poi perdi tutti gli strumenti utili che ottieni dal gocomando. Tutti si aspettano che il codice si trovi nella gerarchia GOPATH standard.

Hai menzionato go install, ma anche go test(e il simpatico go test -coverstrumento di copertura) non funzionerà go get, il che ti consente di scaricare il codice remoto scriverà tutto su GOPATH, quindi dovrai copiarlo.

Certo, puoi sostituire tutto con make / scons / cmake / qualunque cosa e fare le cose e probabilmente funzionerà per il tuo ambiente, ma è un lavoro extra che potrebbe essere fatto dallo gostrumento.

(disclaimer: mi piace progettare cose come questa ma sono nuovo di Go, non l'ho provato in pratica)

Idea: perché non entrambi?

Sono disponibili due opzioni polari se si tiene conto del collegamento simbolico:

(A) Codice in src, collegato simbolicamente allo spazio di lavoro

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

(B) Codice nell'area di lavoro, collegato simbolicamente 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

Mi sposto verso "A" perché:

• tutte le tue fonti vivono vicine fisicamente,
• projectname può avere facilmente un proprio repository oppure puoi avere un repository per l'intero progetto,
• puoi tenere tutto senza controllo go_workspacee inizializzarlo attraverso una fase di creazione (usando godepquindi il collegamento simbolico al progetto)

Aggiornamento 2019

Non è più necessario archiviare il progetto in GOPATH .

Mettilo in una directory al di fuori di GOPATH. Quindi digitare:

go mod init github.com/youruser/yourproject

Sarai bravo ad andare.