Ciao a tutti! Come avrete notato sono molto interessato a Go e da quando mi sono innamorato di questo linguaggio mi piacerebbe scriverne più frequentemente.

Se non conoscete ancora Go penso proprio che dovreste impararlo. Go è fantastico!

Go è un linguaggio relativamente giovane e quando si tratta di vendoring e gestione delle dipendenze non è ancora molto maturo. La comunità di Go, tuttavia, sta adottando alcune pratiche e creando strumenti per soddisfare questa domanda. Questo è ciò di cui parleremo oggi.

Comprendere l’ecosistema di Go

Go mira ad usare la semplicità per realizzare compiti complessi e quindi rendere il linguaggio più divertente e produttivo. Fin dall’inizio del linguaggio, il team di Go ha scelto di usare i letterali di stringa per rendere la sintassi di importazione arbitraria per descrivere ciò che veniva importato.

Questo è ciò che è scritto nei loro stessi documenti:

Un obiettivo esplicito per Go fin dall’inizio era quello di essere in grado di costruire il codice Go usando solo le informazioni trovate nel sorgente stesso, senza bisogno di scrivere un makefile o uno dei molti sostituti moderni per i makefile. Se Go avesse avuto bisogno di un file di configurazione per spiegare come costruire il programma, allora Go avrebbe fallito.

Per raggiungere questo obiettivo, il team di Go preferisce le convenzioni alle configurazioni. Queste sono le convenzioni adottate quando si tratta della gestione dei pacchetti:

1. Il percorso di importazione è sempre derivato in modo noto dall’URL del codice sorgente. Questo è il motivo per cui le tue importazioni appaiono come: github.com/author/pkgname. Facendo questo otteniamo anche uno spazio dei nomi gestito automaticamente, poiché questi servizi online gestiscono già percorsi unici per ogni pacchetto.
2. Il luogo in cui memorizziamo i pacchetti nel nostro file system è derivato in modo noto dal percorso di importazione. Se cerchi dove go memorizza i pacchetti che scarichi, sarai in grado di metterlo in relazione con l’URL da cui è stato scaricato.
3. Ogni directory in un albero sorgente corrisponde a un singolo pacchetto. Questo rende più facile per voi trovare il codice sorgente per certi pacchetti e vi aiuta ad organizzare il vostro codice in modo standardizzato. Legando la struttura delle cartelle a quella dei pacchetti non abbiamo bisogno di preoccuparci di entrambe contemporaneamente, perché gli strumenti del file system diventano strumenti di gestione dei pacchetti.
4. Il pacchetto è costruito usando solo informazioni dal codice sorgente. Questo significa niente makefiles e niente configuration e vi libera dal dover adottare specifiche (e probabilmente complicate) catene di strumenti.

Ora che abbiamo detto questo, è facile capire perché il comando go get funziona come funziona.

Comprensione dei comandi di Go Tools

Prima di addentrarci in questi comandi cerchiamo di capire cos’è il “$GOPATH“.

Il $GOPATH è una variabile d’ambiente che punta a una directory che può essere considerata come una directory dello spazio di lavoro. Conterrà i tuoi codici sorgente, i pacchetti compilati e i binari eseguibili.

go get

Il comando go get è semplice e funziona quasi come un git clone. L’argomento che devi passare a go get è un semplice URL del repository. In questo esempio, useremo il comando go get https://github.com/golang/oauth2.

Quando si esegue questo comando, go semplicemente recupera il pacchetto dall’URL che hai fornito e lo mette nella tua directory $GOPATH. Se navighi nella tua cartella $GOPATH vedrai che ora hai una cartella in src/github.com/golang/oauth2 che contiene i file sorgente del pacchetto e un pacchetto compilato nella directory pkg (insieme alle sue dipendenze).

Ogni volta che si esegue go get si dovrebbe avere in mente che qualsiasi pacchetto scaricato sarà posto in una directory che corrisponde all’URL utilizzato per scaricarlo.

Ha anche un mucchio di altri flag disponibili, come -u che aggiorna un pacchetto o -insecure che permette di scaricare pacchetti utilizzando schemi insicuri come HTTP. Puoi leggere di più sull’uso “avanzato” del comando go get a questo link.

Inoltre, secondo go help gopath, il comando go get aggiorna anche i sottomoduli dei pacchetti che stai ricevendo.

go install

Quando si esegue go install nella directory dei sorgenti di un pacchetto si compila l’ultima versione di quel pacchetto e tutte le sue dipendenze nella directory pkg.

go build

Go build è responsabile della compilazione dei pacchetti e delle loro dipendenze, ma non installa i risultati!

Comprensione del Vendoring

Come avrete notato dal modo in cui Go salva le sue dipendenze, questo approccio alla gestione delle dipendenze ha alcuni problemi.

Prima di tutto, non siamo in grado di determinare quale versione di un pacchetto ci serve a meno che non sia ospitata in un repository completamente diverso, altrimenti go get recupererà sempre l’ultima versione di un pacchetto. Questo significa che se qualcuno fa un cambiamento radicale al suo pacchetto e non lo mette in un altro repo tu e il tuo team finirete nei guai perché potreste finire per recuperare versioni diverse dello stesso pacchetto e questo porterà a problemi di “funziona sulla mia macchina”.

Un altro grosso problema è che, a causa del fatto che go get installa i pacchetti nella root della tua directory src, non potrai avere versioni diverse delle tue dipendenze per ognuno dei tuoi progetti. Questo significa che non puoi avere progetti che dipendono da versioni diverse dello stesso pacchetto, dovrai avere una versione o l’altra alla volta.

Per mitigare questi problemi, da Go 1.5, il team di Go ha introdotto una caratteristica vendoring. Questa caratteristica ti permette di mettere il codice della tua dipendenza per un pacchetto all’interno della sua propria directory in modo che possa ottenere sempre le stesse versioni per tutte le build.

Diciamo che hai un progetto chiamato awesome-project che dipende da popular-package. Per garantire che tutti nel vostro team usino la stessa versione di popular-package potete mettere il suo sorgente dentro $GOPATH/src/awesome-project/vendor/popular-package. Questo funzionerà perché Go cercherà di risolvere il percorso delle vostre dipendenze partendo dalla directory vendor della sua stessa cartella (se ha almeno un file .go) invece di $GOPATH/src. Questo renderà anche le vostre compilazioni deterministiche (riproducibili) poiché useranno sempre la stessa versione di popular-package.

È anche importante notare che il comando go get non metterà automaticamente i pacchetti scaricati nella cartella vendor. Questo è un lavoro per gli strumenti di vendoring.

Quando si usa il vendoring si potranno usare gli stessi percorsi di importazione come se non lo si facesse, perché Go cercherà sempre di trovare le dipendenze nella directory vendor più vicina. Non c’è bisogno di anteporre vendor/ a nessuno dei tuoi percorsi di importazione.

Per poter comprendere appieno come funziona il vendoring dobbiamo capire l’algoritmo usato da Go per risolvere i percorsi di importazione, che è il seguente:

1. Cercare l’importazione nella directory locale vendor (se esiste)
2. Se non riusciamo a trovare questo pacchetto nella directory locale vendor saliamo nella cartella padre e proviamo a trovarlo nella directory vendor (se
3. Ripetiamo il passo 2 fino a raggiungere $GOPATH/src
4. Cerchiamo il pacchetto importato in $GOROOT
5. Se non troviamo questo pacchetto in $GOROOT lo cerchiamo nella nostra cartella $GOPATH/src

In pratica, questo significa che ogni pacchetto può avere le proprie dipendenze risolte nella propria cartella vendor. Se dipendete dal pacchetto x e dal pacchetto y, per esempio, e anche il pacchetto x dipende dal pacchetto y ma ha bisogno di una versione diversa di esso, sarete ancora in grado di eseguire il vostro codice senza problemi, perché x cercherà y nella sua cartella vendor mentre il vostro pacchetto cercherà y nella cartella vendor del vostro progetto.

Ora, un esempio pratico. Diciamo che hai questa struttura di cartelle:

$GOPATH src/ github.com/user/package-one/ one.go myproject main.go vendor/ github.com/user/package-one/ one.go client/ client.go vendor/ github.com/user/package-one/ server/ server.go vendor/ github.com/user/package-one/ one.go

Se importassimo github.com/user/package-one da dentro main.go si risolverebbe alla versione di questo pacchetto nella directory vendor nella stessa cartella:

$GOPATH src/ github.com/user/package-one/ one.go myproject main.go <-- Importing package-one from here vendor/ github.com/user/package-one/ <-- resolves to here one.go client/ client.go vendor/ github.com/user/package-one/ server/ server.go vendor/ github.com/user/package-one/ one.go

Ora se importiamo lo stesso pacchetto in client.go si risolverà anche questo pacchetto nella cartella vendor nella propria directory:

$GOPATH src/ github.com/user/package-one/ one.go myproject main.go vendor/ github.com/user/package-one/ one.go client/ client.go <-- Importing package-one from here vendor/ github.com/user/package-one/ <-- resolves to here server/ server.go vendor/ github.com/user/package-one/ one.go

$GOPATH src/ github.com/user/package-one/ one.go myproject main.go vendor/ github.com/user/package-one/ one.go client/ client.go vendor/ github.com/user/package-one/ server/ server.go <-- Importing package-one from here vendor/ github.com/user/package-one/ <-- resolves to here one.go