Koppeln Sie Ihren Go-Code nicht an GitHub
Don't couple your Go code to GitHub
Go importiert Pakete über ihre URL, wodurch der Code an den Git-Host gebunden wird. Ein Umzug zu GitLab oder einem anderen Anbieter erfordert dann Änderungen am Quellcode. Iain Cambridge zeigt, wie eigene Domains wie go.iain.rocks dieses Problem lösen: Der Importpfad bleibt stabil, während der Host im Hintergrund wechselt. Er liefert fertige Nginx- und HTML-Konfigurationen, damit Teams ihre internen Bibliotheken ohne unnötige Abhängigkeiten betreiben können.
Man ist also buchstäblich mit seinem Code an GitHub gekoppelt. Was völlig verrückt klingt, aber in der Go-Community so gut wie de facto ist.
- jerf
Das versteckt sich in der Verschleierung, zu spezifisch zu sein. Das Problem ist allgemein. Um ein Paket zu benennen, muss man sich in irgendeiner Art von Namespace befinden. Da das Universum keine Art von abstraktem, umgebendem "Namespace" bereitstellt, auf den wir uns alle berufen können, sind alle Namespaces menschliche Konstrukte. Als menschliche Konstrukte können sie versagen.
In dieser Terminologie läuft der Artikel im Grunde darauf hinaus zu sagen: "Dieser Namespace kann versagen! Die Lösung ist, einen anderen zu verwenden!"
Aber das bringt einen nirgendwohin, denn der neue Namespace kann auch versagen. Tatsächlich ist es fast sicher, dass er früher versagen wird als "github.coms DNS und Hosting" als Namespace.
Es gibt keine Lösung, bei der man sein Software-Release an einen Namespace bindet, der nicht versagen kann, denn es gibt keinen Namespace, der nicht versagen kann. Es spielt keine Rolle, ob deine Lieblingssprache DNS verwendet oder ein zentral gesegnetes Repository hat oder ob sie eine gesegnete Liste von Paketnamen mit der Sprache selbst oder irgendetwas anderem verteilt. Der Namespace kann versagen.
Daher ist das Einzige, was man wirklich tun kann, widerstandsfähig gegen Fehler zu sein, und in vielerlei Hinsicht ist die einzige praktische Lösung für Widerstandsfähigkeit einfach anzunehmen, dass, wenn in Zukunft jemand Probleme hat, ein Paket aufgrund eines Namespace-Fehlers zu bekommen, er nicht hilflos in einem Tränenmeer zerfließt, während dein Code für immer verloren ist, sondern dass die zukünftige Person stattdessen dieses vollkommen lösbare Problem lösen wird.
- rot256
Paketverwaltung in Go fühlte sich immer ziemlich hacky an. Unter den Problemen ist die Verwechslung zwischen "was etwas ist" und "wo etwas ist". Am Anfang gab es nicht einmal eine Möglichkeit, verschiedene Versionen eines Pakets zu haben, mit der Begründung, dass man einfach eine Schnittstelle reparieren und sie bis zum Ende aller Zeiten stabil halten sollte; es gab auch keine Möglichkeit, "Abhängigkeiten zu sperren", sodass man zur Build-Zeit bekam, was das Repo gerade lieferte. Es ist seitdem besser geworden, aber immer noch einige holprige Stellen als Ergebnis des "Wachsenlassens" eines Paketsystems.
- thih9
> Meiner Meinung nach sollte jedes kommerzielle Softwareentwicklungsteam, das Go verwendet, benutzerdefinierte Domains für das Namespacing seiner internen Bibliotheken und Pakete verwenden.
Ich würde "Go" aus dem Obigen entfernen, d.h. ich denke, dasselbe gilt für andere Stacks.
Selbst die Verwendung von GitHub-Domain-Links in Codekommentaren wird langfristig problematisch. Z.B. wenn eine Migration stattfindet und diese Links anfangen, nirgendwohin zu zeigen.
- dewey
> Das heißt, wenn du dein Git-Hosting zu GitLab verschiebst, musst du deinen Code ändern!
Du kannst auch einfach "replace github.com/example/example => gitlab.com/example/example" in deiner go.mod-Datei verwenden und alles funktioniert weiter. Das scheint eine sehr verfrühte Optimierung für etwas zu sein, das nicht wirklich wichtig ist.
- farthest
Was passiert also, wenn der Domain-Anbieter gekauft wird und die Domain in deinem OSS-Projekt versteigert und kompromittiert wird? Das scheint Schildkröten bis ganz nach unten zu sein..
- p4bl0
Stimmt, aber Vorsicht mit dem Domainnamen, den du verwendest. Denn VeriSign kann einseitig beschließen, deinen Domainnamen zusammen mit Tausenden anderen zu löschen [1] und du bist wieder am Anfang…
- unscaled
> Eine der guten Eigenschaften von Go ist, dass man seinen Code mit dem Ort namespace't, an dem der Code abgerufen wird.
Dann erklärt der Rest des Artikels, warum dies in der Praxis KEINE gute Eigenschaft ist.
Ich denke auch nicht, dass es undurchführbar ist, aber dies ist eines dieser kleinen Dinge, die Go anders machen wollte und seine Fans davon überzeugt hat, dass dies eine großartige Idee ist und alle anderen Sprachen es falsch machen. Nach ein paar Stolpersteinen wird uns jetzt, anstatt zuzugeben, dass es einige Vorteile hat, offizielle Paketnamen zu haben, gesagt, dass jeder einfach seine eigene benutzerdefinierte Domain mit einem nginx-Server oder einem Go Vanity URLs Forwarder einrichten sollte, um Traffic für seine auf GitHub gehosteten Pakete zu bedienen.
- st3fan
Großartig, wenn ein Unternehmen pleitegeht und die Domains in der Luft hängen. Der Nächste, der sie aufschnappt, übernimmt Quellcode, von dem andere neu abhängen. Wir haben das in anderen Ökosystemen schon oft gesehen. Es ist eine sehr schlechte Situation.
Es ist ein schlechter Rat, deine Pakete unter deine eigene Domain zu verschieben. Du wirst niemals so gut wie Microsoft darin sein, weiter für die Domain zu zahlen. Es gibt keine Garantien im Leben, aber ich garantiere dir, dass, wenn du pleitegehst, diese Domain das Letzte ist, woran du denken wirst.