Artikel geschrieben im Februar 2018.

Go muss die Paketversionierung hinzufügen.

Genauer gesagt müssen Sie das Konzept der Versionierung in das Arbeitswörterbuch und die Tools der Go-Entwickler aufnehmen, damit jeder die gleichen Versionsnummern verwendet, wenn er angibt, welches Programm erstellt, ausgeführt oder analysiert werden soll. Der Befehl go sollte genau angeben, welche Versionen welcher Pakete sich in einer bestimmten Assembly befinden.

Mit der Versionsnummerierung können Sie reproduzierbare Assemblys erstellen: Wenn ich die neueste Version meines Programms veröffentliche, erhalten Sie nicht nur die neueste Version meines Codes, sondern auch genau die gleichen Versionen aller Pakete, von denen mein Code abhängt, sodass wir vollständig äquivalente Binärdateien erstellen.

Durch die Versionierung wird auch sichergestellt, dass das Programm morgen genau so erstellt wird wie heute. Selbst wenn neue Versionen von Abhängigkeiten veröffentlicht werden, werden sie von go nicht ohne einen speziellen Befehl verwendet.

Obwohl Sie die Versionskontrolle hinzufügen müssen, sollten Sie die Hauptvorteile des Befehls go nicht aufgeben: Es ist einfach, schnell und verständlich. Heutzutage achten viele Programmierer nicht auf die Versionen und alles funktioniert gut. Wenn Sie das richtige Modell herstellen, achten die Programmierer immer noch nicht auf die Versionsnummern, sondern alles funktioniert besser und wird klarer. Bestehende Workflows werden sich kaum ändern. Die Veröffentlichung neuer Versionen ist sehr einfach. Im Allgemeinen sollte die Versionskontrolle auf der Strecke bleiben und die Aufmerksamkeit des Entwicklers nicht auf sich ziehen.

Kurz gesagt, Sie müssen die Versionskontrolle des Pakets hinzufügen, aber nicht break go get . In diesem Artikel schlagen wir vor, wie dies zu tun ist, und zeigen einen Prototyp, den Sie jetzt ausprobieren können und der hoffentlich die Grundlage für eine mögliche go Integration wird. Ich hoffe, dieser Artikel ist der Beginn einer produktiven Diskussion darüber, was funktioniert und was nicht. Basierend auf dieser Diskussion werde ich sowohl meinen Vorschlag als auch den Prototyp anpassen und dann den offiziellen Vorschlag zum Hinzufügen einer optionalen Funktion zu Go 1.11 vorstellen.

Dieser Vorschlag behält alle Vorteile von go get , fügt jedoch reproduzierbare Builds hinzu, unterstützt die semantische Versionskontrolle, eliminiert die Vendorisierung, entfernt GOPATH zugunsten eines projektbasierten Workflows und bietet eine reibungslose Abkehr von dep und seinen Vorgängern. Dieser Vorschlag befindet sich jedoch noch in einem frühen Stadium. Wenn die Details nicht korrekt sind, werden wir sie beheben, bevor die Arbeit in die Go-Hauptdistribution gelangt.

Allgemeine Situation

Bevor wir den Vorschlag prüfen, schauen wir uns die aktuelle Situation an und wie wir dazu gekommen sind. Dieser Abschnitt mag etwas zu groß sein, aber die Geschichte bringt wichtige Lektionen und hilft zu verstehen, warum wir etwas ändern wollen. Wenn dies für Sie nicht interessant ist, können Sie sofort zum Angebot gehen oder den zugehörigen Blog-Artikel mit einem Beispiel lesen.

Makefile , goinstall und go get

Im November 2009 wurden der Compiler, der Linker und mehrere Bibliotheken mit der ersten Version von Go veröffentlicht. Um die Programme zu kompilieren und zu verknüpfen, mussten 6g und 6l , und wir haben Beispiel-Makefiles in das Kit aufgenommen. Die minimale gobuild Shell könnte ein Paket kompilieren und das entsprechende Makefile schreiben (in den meisten Fällen). Es gab keine etablierte Möglichkeit, den Code mit anderen zu teilen. Wir wussten, dass dies nicht genug war - aber wir veröffentlichten, was wir hatten, und planten, den Rest zusammen mit der Community zu entwickeln.

Im Februar 2010 schlugen wir goinstall vor , einen einfachen Befehl zum Herunterladen von Paketen aus Repositorys von Versionskontrollsystemen wie Bitbucket und GitHub. Goinstall Konventionen für Goinstall eingeführt, die jetzt allgemein akzeptiert werden. Zu diesem Zeitpunkt folgte jedoch kein Code diesen Konventionen. goinstall funktionierte zunächst nur mit Paketen, die nur die Standardbibliothek importierten. Die Entwickler gingen jedoch schnell zu einer einzigen Vereinbarung über, die wir heute kennen, und die veröffentlichten Go-Pakete haben sich zu einem ganzheitlichen Ökosystem entwickelt.

Goinstall hat auch die Makefiles und damit die Komplexität der benutzerdefinierten Build-Optionen behoben. Obwohl es manchmal unpraktisch ist, dass Paketautoren nicht bei jedem Build Code generieren können, ist diese Vereinfachung für Paketbenutzer unglaublich wichtig: Sie müssen sich nicht um die Installation derselben Tools kümmern, die der Autor verwendet hat. Diese Vereinfachung ist auch für den Betrieb der Werkzeuge von entscheidender Bedeutung. Makefile ist ein erforderliches schrittweises Rezept zum Kompilieren eines Pakets. und das Anwenden eines anderen Werkzeugs wie go vet oder Autocompletion auf dasselbe Paket kann ziemlich schwierig sein. Selbst das korrekte Abrufen von Abhängigkeiten, um Pakete bei Bedarf und nur bei Bedarf neu zu erstellen, ist mit beliebigen Makefiles viel komplizierter. Obwohl zu dieser Zeit einige Leute Einwände dagegen erhoben, dass ihnen die Flexibilität entzogen wurde, wird im Rückblick klar, dass das Aufgeben des Makefiles der richtige Schritt war: Die Vorteile überwiegen bei weitem die Unannehmlichkeiten.

Im Dezember 2011 haben wir in Vorbereitung auf Go 1 den Befehl go eingeführt , der goinstall durch go get ersetzte.

Im Allgemeinen werden wichtige Änderungen eingeführt: Go-Entwickler konnten Quellcode austauschen und die Arbeit des anderen nutzen. Er isolierte auch Teile des Build-Systems innerhalb des Befehls go , so dass eine signifikante Automatisierung mit Hilfe von Werkzeugen möglich wurde. Aber go get fehlt das Konzept der Versionskontrolle. In den ersten Diskussionen über goinstall wurde klar: Sie müssen etwas mit der Versionskontrolle tun. Leider war nicht klar, was genau zu tun ist. Zumindest haben wir im Go-Team dies nicht klar verstanden. Wenn go get ein Paket anfordert, erhält es immer die neueste Kopie und delegiert Download- und Aktualisierungsvorgänge an ein Versionskontrollsystem wie Git oder Mercurial. Eine solche "blinde Arbeit" hat zu mindestens zwei signifikanten Mängeln geführt.

Versionierung und API-Stabilität

Der erste große Nachteil von go get ist, dass es ohne das Konzept der Versionskontrolle dem Benutzer nichts darüber sagen kann, welche Änderungen in diesem Update zu erwarten sind.

Im November 2013 wurde in einer Version von Go 1.2 ein FAQ-Eintrag mit solchen Hinweisen zur Versionierung hinzugefügt (der Text wurde nicht in Version Go 1.10 geändert):

Pakete für den allgemeinen Gebrauch sollten während der Entwicklung die Abwärtskompatibilität beibehalten. Die Kompatibilitätsempfehlungen für Go 1 sind hier relevant: Löschen Sie keine exportierten Namen, fördern Sie das Markieren von zusammengesetzten Literalen usw. Wenn neue Funktionen erforderlich sind, fügen Sie einen neuen Namen hinzu, anstatt den alten zu ändern. Erstellen Sie im Falle einer grundlegenden Änderung ein neues Paket mit einem neuen Importpfad.

Im März 2014 startete Gustavo Niemeyer gopkg.in unter dem Deckmantel "stabiler APIs für die Go-Sprache". Diese Domain ist eine versionierungsspezifische GitHub-Umleitung, mit der Pfade wie gopkg.in/yaml.v1 und gopkg.in/yaml.v2 für verschiedene Commits (möglicherweise in verschiedenen Zweigen) eines Git-Repositorys importiert werden können. Gemäß der semantischen Versionierung sollten Autoren bei kritischen Änderungen eine neue Hauptversion veröffentlichen. Daher ersetzen spätere Versionen des v1 Importpfads die vorherigen, und v2 kann völlig andere APIs bereitstellen.

Im August 2015 reichte Dave Cheney einen Vorschlag zur semantischen Versionskontrolle ein . In den nächsten Monaten löste dies eine interessante Diskussion aus: Alle schienen sich einig zu sein, dass das semantische Markieren von Versionen eine großartige Idee ist, aber niemand wusste, wie die Tools mit diesen Versionen funktionieren sollten.

Alle Argumente für eine semantische Versionierung werden unweigerlich unter Bezugnahme auf das Hyrumsche Gesetz kritisiert:

Der Vertrag Ihrer API wird bei einer ausreichenden Anzahl von Benutzern unwichtig. Jemand hängt von einem beobachteten Verhalten des Systems ab.

Obwohl das Hyrumsche Gesetz empirisch korrekt ist, ist die semantische Versionskontrolle immer noch ein nützlicher Weg, um Erwartungen über die Beziehung zwischen Releases zu generieren. Ein Upgrade von 1.2.3 auf 1.2.4 sollte Ihren Code nicht beschädigen, und ein Upgrade von 1.2.3 auf 2.0.0 kann sehr gut sein. Wenn der Code nach dem Update auf 1.2.4 nicht mehr funktioniert, akzeptiert der Autor höchstwahrscheinlich einen Fehlerbericht und behebt den Fehler in Version 1.2.5. Wenn der Code nach dem Update auf 2.0.0 nicht mehr funktioniert (oder sogar kompiliert wurde), war diese Änderung mit größerer Wahrscheinlichkeit beabsichtigt, und dementsprechend ist es unwahrscheinlich, dass in 2.0.1 etwas behoben wird.

Ich möchte aus Hirams Gesetz nicht schließen, dass eine semantische Versionierung unmöglich ist. Stattdessen bin ich der Meinung, dass Assemblys sorgfältig verwendet werden sollten und genau die gleichen Versionen jeder Abhängigkeit wie der Autor verwenden sollten. Das heißt, die Standardbaugruppe sollte so reproduzierbar wie möglich sein.

Verkaufsautomaten und reproduzierbare Baugruppen

Der zweite große Nachteil von go get ist, dass ein Team ohne das Konzept der Versionskontrolle die Idee eines reproduzierbaren Builds nicht bereitstellen und sogar ausdrücken kann. Sie können nicht sicher sein, dass Benutzer dieselbe Version der Code-Abhängigkeiten wie Sie kompilieren. Im November 2013 wurden die folgenden FAQ zu den FAQ für Go 1.2 hinzugefügt:

Wenn Sie ein externes Paket verwenden und befürchten, dass es sich unerwartet ändert, besteht die einfachste Lösung darin, es in das lokale Repository zu kopieren (dieser Ansatz wird von Google verwendet). Speichern Sie eine Kopie mit einem neuen Importpfad, der sie als lokale Kopie identifiziert. Sie können beispielsweise original.com/pkg nach you.com/external/original.com/pkg . Eines der Werkzeuge für dieses Verfahren ist Kit Reriks Goven.

Keith Rarik hat dieses Projekt im März 2012 gestartet. Das Dienstprogramm goven kopiert die Abhängigkeit in das lokale Repository und aktualisiert alle goven , um den neuen Speicherort goven . Solche Quellcodeänderungen sind notwendig, aber unangenehm. Sie erschweren das Vergleichen und Einfügen neuer Kopien und erfordern auch das Aktualisieren von anderem kopiertem Code unter Verwendung dieser Abhängigkeit.

Im September 2013 führte Keith godep ein , "ein neues Tool zum Beheben von Paketabhängigkeiten ". Die Hauptleistung von godep war das, was wir jetzt als Vendoring bezeichnen, godep das Kopieren von Abhängigkeiten in das Projekt, ohne die Quelldateien zu ändern, ohne direkte Unterstützung für die Tools durch eine bestimmte Konfiguration von GOPATH.

Im Oktober 2014 schlug Keith vor, Go-Tools um Unterstützung für „externe Pakete“ zu erweitern, damit Tools Projekte, die diese Konvention verwenden, besser verstehen. Zu diesem Zeitpunkt waren bereits mehrere Dienstprogramme im godep Stil erschienen. Matt Farina veröffentlichte einen Beitrag „Travelling the Sea of ​​Go- godep “, in dem er godep mit godep , insbesondere mit glide .

Im April 2015 führte Dave Cheney gb ein , „ein projektbasiertes Build-Tool ... mit wiederholten Builds durch Quellenverkauf“, ohne die Importpfade neu zu schreiben (eine weitere Motivation für die Erstellung von gb bestand darin, die Notwendigkeit zu vermeiden, Code in bestimmten Verzeichnissen in GOPATH zu speichern was nicht immer bequem ist).

In diesem Frühjahr untersuchte Jason Buberlie die Situation mit Go-Paketverwaltungssystemen, einschließlich mehrfacher Doppelarbeit und der vergeblichen Arbeit an ähnlichen Dienstprogrammen. Seine Umfrage machte Entwicklern klar, dass die Unterstützung für den Verkauf ohne Umschreiben von Importpfaden zum Befehl go hinzugefügt werden muss. Gleichzeitig begann Daniel Theofanes, Spezifikationen für ein Dateiformat zu erstellen, das den genauen Ursprung und die Version des Codes im Verzeichnis des Anbieters beschreibt. Im Juni 2015 haben wir den Vorschlag von Keith als Experiment zum Verkauf in Go 1.5 akzeptiert, der standardmäßig in Go 1.6 enthalten war. Wir haben die Autoren aller Verkaufstools ermutigt, mit Daniel zusammenzuarbeiten, um ein einziges Metadatendateiformat zu verwenden.

Durch die Einführung des Vending-Konzepts in Go konnten Tools wie vet Programme kompetenter analysieren. Heute wurde es von einem Dutzend oder zwei Paketmanagern oder Vending-Tools verwendet. Da jedoch jeder unterschiedliche Metadatenformate hat, interagieren sie nicht und können Abhängigkeitsinformationen nicht einfach austauschen.

Grundsätzlich ist der Verkauf eine unvollständige Lösung für das Problem der Versionskontrolle. Es bietet nur die Reproduzierbarkeit der Baugruppe, hilft jedoch nicht, die Paketversionen zu verstehen und zu entscheiden, welche verwendet werden soll. Paketmanager wie glide und dep fügen Go implizit das Konzept der Versionskontrolle hinzu und dep das Herstellerverzeichnis auf eine bestimmte Weise ein. Infolgedessen können viele Tools im Go-Ökosystem möglicherweise nicht die richtigen Versionsinformationen abrufen. Es ist klar, dass Go direkte Unterstützung für Paketversionen benötigt.

Offizielles Paketmanagement-Experiment

Auf der GopherCon 2016 am Hack Day (jetzt Community Day) versammelte sich eine Gruppe von Go-Aktivisten, um Fragen der Paketverwaltung umfassend zu diskutieren . Eines der Ergebnisse war die Bildung eines Ausschusses und einer Beratergruppe zur Durchführung einer Reihe von Aktivitäten mit dem Ziel, ein neues Paketmanagement-Tool zu schaffen . Die Idee war, ein einheitliches Tool vorhandene ersetzen zu lassen, obwohl es weiterhin außerhalb des direkten Toolkits von Go mithilfe von Anbieterkatalogen implementiert werden würde. Dem Ausschuss gehörten Andrew Gerrand, Ed Müller, Jesse Frazel und Sam Boyer unter der Leitung von Peter Burgon an. Sie bereiteten einen Entwurf für eine Spezifikation vor , und dann implementierten Sam und seine Assistenten dep . Ein Verständnis der allgemeinen Situation finden Sie in Sams Artikel vom Februar 2016 „So möchten Sie einen Paketmanager schreiben“, in seinem Beitrag „Go Dependency Management Saga“ vom Dezember 2016 und in seiner Rede im Juli 2017 auf der GopherCon „Eine neue Ära des Paketmanagements in Geh . "

Dep führt viele Aufgaben aus: Dies ist eine wichtige Verbesserung gegenüber den derzeitigen Praktiken. Dies ist ein wichtiger Schritt in Richtung einer zukünftigen Lösung und gleichzeitig ein Experiment - wir nennen es ein „offizielles Experiment“ -, das uns hilft, die Bedürfnisse von Entwicklern besser zu verstehen. dep kein direkter Prototyp für die mögliche Integration von go Befehlen in die Paketversionierung. Dies ist eine leistungsstarke, flexible und nahezu universelle Möglichkeit, den Raum für Designentscheidungen zu erkunden. Es ähnelt den Makefiles, gegen die wir am Anfang gekämpft haben. Sobald wir jedoch den Raum für Entwurfsentscheidungen besser verstehen und ihn auf einige wichtige Funktionen eingrenzen können, die unterstützt werden sollten, wird dies dem Go-Ökosystem helfen, andere Funktionen zu entfernen, die Ausdruckskraft zu verringern und verbindliche Konventionen zu übernehmen, die Go-Codebasen konsistenter und verständlicher machen.

Dieser Artikel ist der Beginn des nächsten Schritts nach dep : der erste Prototyp der endgültigen Integration mit dem Befehl go , dem Batch-Äquivalent von goinstall . Ein Prototyp ist ein separater Befehl, den wir vgo nennen: ein go Ersatz mit Unterstützung für die Paketversionierung. Dies ist ein neues Experiment, und wir werden sehen, was daraus wird. Wie bei der Ankündigung der goinstall sind einige Projekte und Code jetzt mit vgo kompatibel, während andere Änderungen benötigen. Wir werden etwas Kontrolle und Ausdruckskraft entfernen, genau wie die Makefiles entfernt wurden, um das System zu vereinfachen und die Komplexität für die Benutzer zu beseitigen. Vor allem suchen wir Pioniere, die beim Experimentieren mit vgo helfen, um so viele Bewertungen wie möglich zu erhalten.

Das Starten eines Experiments mit vgo bedeutet nicht, die dep Unterstützung zu vgo : Es bleibt verfügbar, bis wir eine vollständige und offene Integration mit go . Wir werden auch versuchen, den endgültigen Übergang von dep zu Integration so reibungslos wie möglich zu gestalten, in welcher Form auch immer diese Integration stattfindet. Projekte, die noch nicht in godep konvertiert wurden, können weiterhin von dieser Konvertierung profitieren (beachten Sie, dass godep und glide aktive Entwicklung gestoppt glide und die Migration nach godep fördern). Vielleicht möchten einige Projekte direkt zu vgo wechseln, wenn dies ihren Anforderungen entspricht.

Angebot

Der Vorschlag, dem Befehl go eine Versionskontrolle hinzuzufügen go besteht aus vier Schritten. Akzeptieren Sie zunächst die Importkompatibilitätsregel , die in den FAQ und in gopkg.in angegeben ist: Neuere Versionen des Pakets mit dem angegebenen Importpfad müssen mit älteren Versionen abwärtskompatibel sein. Verwenden Sie zweitens einen einfachen neuen Algorithmus, der als Auswahl der Mindestversion bezeichnet wird , um zu bestimmen, welche Versionen des Pakets in dieser Assembly verwendet werden. Drittens führen Sie das Konzept des Go- Moduls ein : Gruppen von Paketen, die als Ganzes versioniert sind, und deklarieren die Mindestanforderungen, die durch ihre Abhängigkeiten erfüllt werden müssen. Viertens legen Sie fest, wie Sie all dies in Ihren vorhandenen Befehl go damit sich die grundlegenden Workflows gegenüber heute nicht wesentlich ändern. Im Rest dieses Artikels betrachten wir jeden dieser Schritte. Sie werden in anderen Blog-Artikeln ausführlicher behandelt.

Kompatibilitätsregel importieren

Das Hauptproblem bei Paketverwaltungssystemen sind Versuche, Inkompatibilitäten zu beheben. Beispielsweise erlauben die meisten Systeme, dass Paket B deklariert, dass es Paket D der Version 6 oder höher benötigt, und dass Paket C deklariert, dass es D Version 2, 3 oder 4 benötigt, jedoch nicht Version 5 oder höher. Wenn Sie also B und C in Ihrem Paket verwenden möchten, haben Sie kein Glück: Sie können keine Version von D auswählen, die beide Bedingungen erfüllt, und Sie können nichts tun.

Anstelle eines Systems, das unweigerlich die Zusammenstellung großer Programme blockiert, führt unser Vorschlag eine Importkompatibilitätsregel für Paketautoren ein:

Wenn das alte und das neue Paket denselben Importpfad haben, muss das neue Paket abwärtskompatibel mit dem alten Paket sein.

Die Regel wiederholt die zuvor erwähnten FAQ. Dieser Text endete mit den Worten: "Erstellen Sie im Falle einer radikalen Änderung ein neues Paket mit einem neuen Importpfad."Für eine so große Änderung setzen Entwickler heute auf die semantische Versionskontrolle, daher integrieren wir sie in unseren Vorschlag. Insbesondere kann die Nummer der zweiten und der nachfolgenden Hauptversionen direkt in den Pfad aufgenommen werden:

 import "github.com/go-yaml/yaml/v2" 

In der semantischen Versionskontrolle bedeutet Version 2.0.0 eine radikale Änderung, sodass ein neues Paket mit einem neuen Importpfad erstellt wird. Da jede Hauptversion einen anderen Importpfad hat, kann eine bestimmte ausführbare Go-Datei eine der Hauptversionen enthalten. Dies ist zu erwarten und wünschenswert. Ein solches System unterstützt die Zusammenstellung von Programmen und ermöglicht es Teilen eines sehr großen Programms, unabhängig voneinander von v1 auf v2 zu aktualisieren.

Die Einhaltung der Importkompatibilitätsregel durch die Autoren verhindert Versuche, Inkompatibilitäten zu beheben, indem das Gesamtsystem exponentiell vereinfacht und die Fragmentierung des Paketökosystems verringert wird. In der Praxis brechen Aktualisierungen innerhalb derselben Hauptversion natürlich trotz aller Bemühungen der Autoren manchmal Benutzerpakete. Daher sollten Sie nicht zu oft aktualisieren. Dies bringt uns zum nächsten Schritt.

Minimale Versionsauswahl

, dep cargo , . , . -, « » - , - . , - , , , . -, , , «, X», X .

Unser Vorschlag verwendet einen anderen Ansatz, den ich als Auswahl der Mindestversion bezeichne . Standardmäßig wird die älteste zulässige Version jedes Pakets verwendet. Diese Entscheidung wird sich morgen nicht ändern, da es unmöglich ist, eine ältere Version zu veröffentlichen. Noch besser ist es für einen Paketmanager trivial zu bestimmen, welche Version verwendet werden soll. Ich nenne dies die Wahl der Mindestversion, weil die ausgewählten Versionsnummern minimal sind und weil das System als Ganzes wahrscheinlich auch minimal ist, wodurch fast die gesamte Komplexität bestehender Systeme vermieden wird.

Durch Auswahl der Mindestversion können Module nur die Mindestanforderungen für Abhängigkeiten angeben. Dies sind klar definierte, eindeutige Antworten für Aktualisierungs- und Downgrade-Vorgänge, und diese Vorgänge sind wirklich effektiv. Dieses Prinzip ermöglicht es dem Autor des gesamten Moduls, die Version der Abhängigkeiten anzugeben, die er ausschließen möchte, oder das Ersetzen einer bestimmten Abhängigkeit durch ihre Verzweigung anzugeben, die sich entweder im lokalen Speicher befindet oder als separates Modul veröffentlicht wird. Diese Ausnahmen und Ersetzungen gelten nicht, wenn ein Modul als Abhängigkeit von einem anderen Modul erstellt wird. Dies gibt Benutzern die vollständige Kontrolle darüber, wie ihre eigenen Programme zusammengestellt werden, nicht jedoch über Fremde.

Durch Auswahl der Mindestversion werden standardmäßig reproduzierbare Assemblys ohne Sperrdatei bereitgestellt.

Die Importkompatibilität ist der Schlüssel zur einfachen Auswahl der Mindestversion. Benutzer können nicht mehr "Nein, dies ist eine zu neue Version" sagen, sondern nur "Nein, es ist zu alt". In diesem Fall ist die Lösung klar: Verwenden Sie die (minimale) neuere Version. Und neuere Versionen sind gemäß Konvention akzeptabler Ersatz für ältere.

Go-Module definieren

Ein Go- Modul ist eine Sammlung von Paketen mit einem allgemeinen Importpfadpräfix, das als Modulpfad bezeichnet wird. Ein Modul ist eine Versionskontrolleinheit, und Versionen werden als semantische Zeichenfolgen geschrieben. Bei der Entwicklung mit Git definieren Entwickler eine neue semantische Version des Moduls, indem sie dem Git-Repository des Moduls ein Tag hinzufügen. Obwohl dringend empfohlen wird, semantische Versionen anzugeben, werden auch Links zu bestimmten Commits unterstützt.

In der neuen Datei go.moddefiniert das Modul die Mindestversionsanforderungen für andere Module, von denen es abhängt. Hier ist zum Beispiel eine einfache Datei go.mod:

 // My hello, world. module "rsc.io/hello" require ( "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54 "rsc.io/quote" v1.5.2 ) 

, rsc.io/hello , : golang.org/x/text rsc.io/quote . , go.mod . , - .

, vgo , . rsc.io/quote , github.com/rsc/quote , , 1.5.2. golang.org/x/text . , v0.0.0-yyyymmddhhmmss-commitdefiniert ein bestimmtes Commit an einem bestimmten Datum. Bei der semantischen Versionierung entspricht diese Zeile der Vorabversion v0.0.0 mit dem Bezeichner yyyymmddhhmmss-commit . Die semantischen Regeln der Versionspriorität erkennen solche Vorabversionen vor Version v0.0.0 und führen Zeichenfolgenvergleiche durch. Die Datumsreihenfolge in der Pseudoversion stellt sicher, dass der Zeichenfolgenvergleich mit dem Datumsvergleich übereinstimmt.

Zusätzlich zu diesen Anforderungen können Dateien go.moddie im vorherigen Abschnitt erwähnten Ausnahmen und Ersetzungen angeben, sie gelten jedoch wiederum nur beim Erstellen eines isolierten Moduls und nicht beim Erstellen als Teil eines größeren Programms. All dies wird in den Beispielen gezeigt .

Goinstallund altgo getTools zur Versionskontrolle wie gitund werden aufgerufen, um den Code herunterzuladen hg, was zu vielen Problemen führt, einschließlich Fragmentierung. Beispielsweise können Benutzer ohne bzrden Code nicht aus den Bazaar-Repositorys herunterladen. Im Gegensatz zu diesem System werden Go-Module immer über HTTP in Form von Zip-Archiven ausgegeben. Zuvor gab go getes spezielle Teams für beliebte Code-Hosting-Sites. Jetzt verfügen sie über vgospezielle API-Verfahren zum Empfangen von Archiven von diesen Sites.

Die einheitliche Darstellung von Modulen in Form von Zip-Archiven ermöglicht die einfache Implementierung eines Protokolls und eines Proxyservers zum Laden von Modulen. Unternehmen und einzelne Benutzer haben unterschiedliche Gründe für den Start solcher Proxyserver, einschließlich der Sicherheit und des Wunsches, im Falle des Löschens von Originalen mit zwischengespeicherten Kopien zu arbeiten. Wenn ein Proxy vorhanden ist go.mod, werden die Herstellerverzeichnisse nicht mehr benötigt , um die Zugänglichkeit sicherzustellen und zu bestimmen, welcher Code verwendet werden soll.

Das Team go

go . , , go build , go install , go run go test , . golang.org/x/text Go .

— GOPATH . go.mod , , go.mod , , . git clone , cd , . . GOPATH.

Was weiter?

« Go» , vgo . , vgo . . .

, vgo . . go.mod . , go.mod , dep , glide , glock , godep , godeps , govend , govendor gvt , vgo go.mod .

, Go . , Go, — , go get , GOPATH GOPATH. .

- . , , vgo . , Go 1.11 Go, , Go 1.12 . , go get. Dies ist jedoch ein aggressiver Plan. Wenn Sie für die richtige Funktionalität auf spätere Versionen warten müssen, sollten Sie dies auch tun.

Ich bin sehr besorgt über den Übergang von den alten go getund unzähligen Verkaufsautomaten zum neuen modularen System. Dieser Prozess ist für mich genauso wichtig wie die richtige Funktionalität. Wenn ein erfolgreicher Übergang bedeutet, auf spätere Versionen zu warten, dann sei es auch so.