© Valerii Shkliaev/Shutterstock.com
Des Gophers neue Kleider

Go Modules revisited


Go 1.11 hat einen Paradigmenwechsel eingeleitet. Aus Go Packages werden versionierte Go Modules. Go Modules lösen den GOPATH ab und werden fester Bestandteil der Go Toolchain. Bis jetzt mussten Go Modules explizit aktiviert werden, doch mit Go 1.13 ändert sich das. Ihr lernt, was Go 1.13 in Sachen Go Modules bringt und was sich seit Go 1.11 getan hat.

Mit Go 1.11 wurde Go um Module erweitert. Damit beginnt für Go eine neue Ära, denn aus Go Packages werden versionierte Go Modules. Diese ersetzen nicht nur Packages, sondern auch gleich den GOPATH. So der Plan, denn noch sind Go Modules nur experimentell, daran ändert sich auch mit Go 1.13 nichts. Aber es kommen wichtige neue Funktionen bei den Go Modules hinzu: Sie sollen durch Mirrors schneller und zuverlässiger werden. Und mit Module Authentication werden sie zudem noch sicherer. Klingt vielversprechend, nicht wahr? Aber bevor wir zu den neuen Features kommen, rekapitulieren wir kurz, was Go Modules bringen, außerdem werfen wir einen Blick darauf, wie Go Modules von der Go-Community angenommen werden.

Was Go Modules bringen

Go Modules machen aus Go Packages versionierte Module. Aus dem Pfad des Packages im GOPATH wird der Importpfad des Moduls. Die Version kommt neu hinzu. So wird aus dem Pfad $GOPATH/github.com/gorilla/mux des Packages Gorilla Mux ein Go Module mit Importpfad github.com/gorilla/mux und Version 1.6.2. Der Importpfad des Moduls ersetzt den Pfad des Packages im GOPATH, der damit auf lange Sicht überflüssig wird.

Ein Go Module enthält die beiden Konfigurationsdateien go.mod und go.sum. In der Datei go.mod steht der Importpfad des Moduls und alle Abhängigkeiten des Moduls (mit Importpfad und Version). Die go.sum enthält Hashes aller Modulabhängigkeiten. Anhand der Hashes wird sichergestellt, dass auch zukünftige Builds immer exakt denselben Code des Moduls erhalten.

Go Modules sind ein Teil von Go. Go unterstützt sie seit Version 1.11, allerdings müssen sie mit der Umgebungsvariable GO111MODULE=on aktiviert werden. Bestehende Tools/Kommandos wie go get funktionieren wie gewohnt, auch mit Go Modules. Neu hinzugekommen ist das Go-Tool mod. Mit go mod init wird ein neues Modul erstellt, mit go mod graph wird ein Graph der Modulabhängigkeiten auf der Kommandozeile ausgegeben.

Mit Go Modules wird die Verwaltung der Abhängigkeiten eines Projekts fester Bestandteil von Go, die Communitylösungen wie dep [1] ersetzen sollen, aber auch das mit Go 1.5 eingeführte Vendoring überflüssig machen. Sie sind somit eines der wichtigsten Features auf dem Weg zu Go 2. Eine ausführliche Einführung in Go Module findet ihr unter [2].

Wie Go Modules ankommen

Die Einführung von Go Modules hätte kaum schlechter starten können. Googles Go-Team hat zu lange hinter den Mauern des Googleplex gearbeitet und zu wenig mit der Go-Community außerhalb von Google kooperiert und kommuniziert. Aber ohne die Go-Community geht es nicht. Die Verbreitung und das Angebot von Modulen entscheiden über Erfolg oder Misserfolg von Go Modules. Und die Mehrzahl der Module kommt eben aus der Go-Community. Schauen wir also, wie weit die Umsetzung von Go Modules in großen Open-Source-Projekten gediehen ist und überprüfen daran die Akzeptanz und Umsetzung in der Go-Community. Wir betrachten die vier großen Go-Open-Source-Projekte Kubernetes [3], Packer [4], CockroachDB [5] und Flynn [6], mit Stand August 2019.

Kubernetes nutzt Go Modules seit der Version 1.15 von Juni 2019 [7]. Die Datei go.mod von Kubernetes ist 474 Zeilen groß und enthält viele direkte und indirekte Modulimporte und 294 Modul-Replacements. Die erste Version der go.mod stammt aus dem Januar 2019. Das erste Ticket bezüglich Go Modules gab es im August 2018. Das Kubernetes-Projekt hat also 12 Monate für den Umstieg benötigt. Für ein Projekt mit 1,4 Millionen Zeilen Go-Code finde ich das erstaunlich schnell...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang