Go: Vorschlag: Unterstützung von „Symlinks“ in GOPATH

Ein paar Anmerkungen/Fragen:

• Der Begriff "Repository" ist nicht definiert. Was ist, wenn der Quellcode in GOPATH nicht von einer VSC oder von Subversion stammt, die das Auschecken eines Verzeichnisses unterstützt?
• Wenn ein Repository mehrere öffentliche Binärdateien enthält, ist es nicht erforderlich, Abhängigkeiten mehrmals zu kopieren. Herstellerabhängigkeiten können unter cmd/vendor abgelegt werden.
• Soweit ich das beurteilen kann, löst dieser Vorschlag das Problem "Bibliothek und Programm im selben Repository" nicht.

@kostya-sch

Der Begriff "Repository" ist nicht definiert

Die erste Fußnote gibt Details - es ist die gleiche Definition wie hier angenommen. Aber ich stimme zu, es bleibt immer noch die Frage, ob "Repository" irgendwo formal definiert ist?

Was ist, wenn der Quellcode in GOPATH nicht von einer VSC oder von Subversion stammt, die das Auschecken eines Verzeichnisses unterstützt?

Offene Frage - Ich gebe zu, dass bisher nur Code in Betracht gezogen wurde, der Teil eines "Repositorys" ist. Ich habe unten einen Abschnitt "Offene Fragen" hinzugefügt, der auf diese Frage verweist.

Wenn ein Repository mehrere öffentliche Binärdateien enthält, ist es nicht erforderlich, Abhängigkeiten mehrmals zu kopieren. Herstellerabhängigkeiten können unter cmd/vendor abgelegt werden

Tatsächlich ist dies ein Ansatz, um bereitgestellten Code zwischen Binärdateien zu teilen. Aber der "Symlink"-Ansatz hilft, den Ansatz zu erleichtern, diesen "Anbieter" mit dem Bibliothekscode zu teilen (siehe nächster Punkt).

Soweit ich das beurteilen kann, löst dieser Vorschlag das Problem "Bibliothek und Programm im selben Repository" nicht.

Dieser Vorschlag allein tut es nicht, nein. Aber das im Abschnitt „Motivierendes Beispiel“ verlinkte Repository beschreibt, wie dieses Problem gelöst werden kann, indem eine Kombination aus „Symlinks“ und GOPATH-Ergänzung verwendet wird.

Symlinks sind zu problematisch. Es scheint unklug, sie zuzulassen.