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

Question

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

#1 da (12 voti)
#2 da (9 voti)

31

Sto lavorando a un nuovo progetto usando Go e siamo tutti nuovi a Go. Stiamo seguendo la struttura standard delle directory go e avendo tutto il codice sotto

$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 su un progetto multilingue, ad es. un back-end resto / http basato su Go e un front-end html / javascript. In tal caso, vorrei probabilmente che la struttura del mio progetto assomigliasse a questo:

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

Ma è effettivamente necessario inserire il codice all'interno di GOPATH?

Come tentativo ho creato un piccolo programma in cui il codice sorgente era esterno a GOPATH. Potrei facilmente suddividere il progetto in pacchetti, quindi il pacchetto main potrebbe fare riferimento a un pacchetto foo in una cartella foo/ utilizzando import "./foo" .

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

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 install per installarlo. Anche questo non è un problema. La pipeline di build installa lo strumento.

Tuttavia, consente al build server di non avere il proprio spazio di lavoro all'interno di GOPATH

Questo approccio è scoraggiato? Se è così, perché così?

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

Ricorda 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 è in Shu stage

go

posta Pete 27.01.2015 - 20:57

fonte

2 risposte

Leggi altre domande sui tag go

Tutte le lingue funzionali usano la garbage collection? Esiste un valore reale nell'unità che verifica un controller in ASP.NET MVC?

score 12 · Answer 1

Non sei obbligato a usare GOPATH, ma poi ti perdi tutti gli strumenti utili che ottieni dal comando go . Tutti si aspettano che il codice sia nella gerarchia GOPATH standard.

Hai menzionato go install , ma anche go test (e lo splendido go test -cover strumento di copertura) non funzionerà go get , che ti permette di scaricare codice remoto scriverà tutto su GOPATH, quindi avrai bisogno copiare le cose.

Certo, puoi rimpiazzarlo con make / scons / cmake / qualunque e fare le cose e probabilmente funzionerà per il tuo ambiente, ma il lavoro extra che potrebbe essere fatto dallo strumento go .

score 9 · Answer 2

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

Idea: perché non entrambi?

Sono disponibili due opzioni polari se si prende in considerazione il symlinking:

(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 inclino a "A" perché:

tutte le tue risorse vivono fisicamente vicine,
projectname può facilmente avere il proprio repository, oppure puoi avere un repository per l'intero progetto,
puoi mantenere intere go_workspace non invertite e inizializzarlo tramite un passaggio di creazione (utilizzando godep quindi associando il link al progetto)