© Nishihama/Shutterstock.com, © S&S Media, https://blog.golang.org/gopher, Renee French
Entwickler Magazin
Was es mit den neuen Modulen in Go auf sich hat

Go Modules

Go Packages kennen keine Versionen und keine Abhängigkeiten. Noch nicht. Mit Go 1.11 und dem experimentellen Support für versionierte Go-Module ändert sich das. Go-Module bringen native Unterstützung für Versionen und Module in Go als festen Bestandteil zur Go Toolchain. Go Modules haben den Anspruch, Communitylösungen wie dep oder glide abzulösen und eine neue einheitliche Lösung zu schaffen. Aber gelingt das auch wirklich? Mal sehen …

Jan Stamer


Ein Go-Projekt startet mit einem Package. Noch ohne Version und Abhängigkeiten. Die Abhängigkeiten kommen schnell hinzu. Als HTTP-Router nutzen wir das Package github.com/gorilla/mux, also: go get github.com/gorilla/mux. Weil wir XML verarbeiten, noch etree, also go get github.com/beevik/etree. Das Projekt nimmt Fahrt auf, ein neuer Mitarbeiter kommt dazu. Nicht lange, und wir haben Version 1.0.3 in Produktion, und ein ganzes Team entwickelt Version 1.1.0.

Aber was ist jetzt los? Auf einmal schlagen diverse Tests fehl – die XML-Verarbeitung geht nicht mehr! Da hat doch keiner was geändert, oder? Naja, stimmt nicht ganz. Keiner aus dem Team hat etwas geändert, dafür aber die Entwickler von etree. Der letzte Build hat die Abhängigkeit auf etree via go get github.com/beevik/etree heruntergeladen und damit ein geändertes etree Package bekommen. Denn go get lädt immer den aktuellen Stand des Master Branches eines Packages herunter. Mit diesem Stand von etree schlagen die Tests fehl.

Und jetzt? Bleiben zwei Möglichkeiten: Entweder auf einen Fix von etree warten. Oder die vorherige Version von etree verwenden, indem wir etree ins vendor-Verzeichnis (Abschnitt „Vendoring“) packen und einchecken. Mit Go 1.11 kommt eine neue, dritte Möglichkeit dazu, nämlich Go Modules.

Ein erstes Go-Modul

Also drehen wir die Zeit zurück und starten unser Go-Projekt nochmal neu, diesmal mit Go Modules. Ein Go-Modul sind ein oder mehrere Go Packages mit einer Version und Abhängigkeiten zu anderen Modulen. Jedes Modul hat einen eindeutigen Modulpfad. In Go 1.11 sind Modules noch experimentell und müssen mit der Umgebungsvariable GO111MODULE=on aktiviert werden.

Wir starten unser Projekt mit einem Package (github.com/red6/gomod) im GOPATH. Damit aus dem Projekt ein Go-Modul wird, müssen wir es mit go mod init initialisieren. Liegt das Package im GOPATH, übernimmt Go den Importpfad des Packages github.com/red6/gomod als Modulpfad und erzeugt die Datei go.mod. In der Datei go.mod sind der Modulpfad und alle Abhängigkeiten des Moduls hinterlegt. Bis jetzt steht in der go.mod nur module github.com/red6/gomod.

Jetzt kommt die erste Abhängigkeit auf das Package github.com/gorilla/mux, wie gewohnt via go get github.com/gorilla/mux. Aber welche Version haben wir bekommen? In der go.mod steht Version 1.6.2. Aber warum? Go ermittelt die höchste Version des Packages als höchstes Tag nach semantischer Versionierung. Alternativ kann auch explizit eine Version angegeben werden (Tabelle 1). Go hat jet...

Entwickler Magazin
Was es mit den neuen Modulen in Go auf sich hat

Go Modules

Go Packages kennen keine Versionen und keine Abhängigkeiten. Noch nicht. Mit Go 1.11 und dem experimentellen Support für versionierte Go-Module ändert sich das. Go-Module bringen native Unterstützung für Versionen und Module in Go als festen Bestandteil zur Go Toolchain. Go Modules haben den Anspruch, Communitylösungen wie dep oder glide abzulösen und eine neue einheitliche Lösung zu schaffen. Aber gelingt das auch wirklich? Mal sehen …

Jan Stamer


Ein Go-Projekt startet mit einem Package. Noch ohne Version und Abhängigkeiten. Die Abhängigkeiten kommen schnell hinzu. Als HTTP-Router nutzen wir das Package github.com/gorilla/mux, also: go get github.com/gorilla/mux. Weil wir XML verarbeiten, noch etree, also go get github.com/beevik/etree. Das Projekt nimmt Fahrt auf, ein neuer Mitarbeiter kommt dazu. Nicht lange, und wir haben Version 1.0.3 in Produktion, und ein ganzes Team entwickelt Version 1.1.0.

Aber was ist jetzt los? Auf einmal schlagen diverse Tests fehl – die XML-Verarbeitung geht nicht mehr! Da hat doch keiner was geändert, oder? Naja, stimmt nicht ganz. Keiner aus dem Team hat etwas geändert, dafür aber die Entwickler von etree. Der letzte Build hat die Abhängigkeit auf etree via go get github.com/beevik/etree heruntergeladen und damit ein geändertes etree Package bekommen. Denn go get lädt immer den aktuellen Stand des Master Branches eines Packages herunter. Mit diesem Stand von etree schlagen die Tests fehl.

Und jetzt? Bleiben zwei Möglichkeiten: Entweder auf einen Fix von etree warten. Oder die vorherige Version von etree verwenden, indem wir etree ins vendor-Verzeichnis (Abschnitt „Vendoring“) packen und einchecken. Mit Go 1.11 kommt eine neue, dritte Möglichkeit dazu, nämlich Go Modules.

Ein erstes Go-Modul

Also drehen wir die Zeit zurück und starten unser Go-Projekt nochmal neu, diesmal mit Go Modules. Ein Go-Modul sind ein oder mehrere Go Packages mit einer Version und Abhängigkeiten zu anderen Modulen. Jedes Modul hat einen eindeutigen Modulpfad. In Go 1.11 sind Modules noch experimentell und müssen mit der Umgebungsvariable GO111MODULE=on aktiviert werden.

Wir starten unser Projekt mit einem Package (github.com/red6/gomod) im GOPATH. Damit aus dem Projekt ein Go-Modul wird, müssen wir es mit go mod init initialisieren. Liegt das Package im GOPATH, übernimmt Go den Importpfad des Packages github.com/red6/gomod als Modulpfad und erzeugt die Datei go.mod. In der Datei go.mod sind der Modulpfad und alle Abhängigkeiten des Moduls hinterlegt. Bis jetzt steht in der go.mod nur module github.com/red6/gomod.

Jetzt kommt die erste Abhängigkeit auf das Package github.com/gorilla/mux, wie gewohnt via go get github.com/gorilla/mux. Aber welche Version haben wir bekommen? In der go.mod steht Version 1.6.2. Aber warum? Go ermittelt die höchste Version des Packages als höchstes Tag nach semantischer Versionierung. Alternativ kann auch explizit eine Version angegeben werden (Tabelle 1). Go hat jet...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang