Go: cmd/go: GOPATH=$HOME/go annehmen wenn nicht gesetzt

/cc @adg @broady @campoy @ianlancetaylor @griesemer @robpike @rsc

Ich mag es, aber haben wir eine bestimmte Präferenz für "gocode" und nicht so etwas wie "gopath"?

Wie viele Leute verwenden bereits GOPATH=$HOME/gocode? Es scheint mir nicht viele. Das deutet darauf hin, dass es die falsche Standardeinstellung ist.

"gocode" wird eine Suchmaschine und andere Verwirrung mit dem beliebten Tool github.com/nsf/gocode haben.

Haben wir Informationen darüber, was die meisten Leute tun?

Ich selbst verwende GOPATH=$HOME/gopath.

Daumen hoch hier, wenn du derzeit GOPATH=$HOME verwendest

Daumen hoch hier, wenn du derzeit GOPATH=$HOME/gopath verwendest

Daumen hoch hier, wenn du derzeit GOPATH=$HOME/gocode verwendest

Soll ich eine Twitter-Umfrage auf @golang machen?

@campoy , hört sich gut an. Wahrscheinlich besser, als alle zu diesem Fehler einzuladen.

Wie wäre es mit $HOME/go (was ich benutze).

Siehe auch: http://go-talks.appspot.com/github.com/freeformz/talks/20160712_gophercon/talk.slide#7

$HOME: 8,9 %
$HOME/go: 50,6%
Sonstiges : 40,5%

Ich wünschte wirklich, ich hätte mehr Optionen für diese aufgeteilt.

Abstimmung gestartet: https://twitter.com/golang/status/781189567437164544

Am Mi, 28.09.2016, 10:51 Uhr Edward Muller [email protected]
schrieb:

Wie wäre es mit $HOME/go (was ich benutze).

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -250244110 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

Siehe auch Spalte I hier: https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid =1525640201

@freeformz ,

$HOME/go steht in Konflikt mit dem Pfad go Quellcode (go.googlesource.com/go) wird oft ausgecheckt. Es ist schlecht, dass die Community diesen Speicherort als Standard für GOPATH gesegnet hat :( Ich mache mir Sorgen, wenn jemand vergisst, seinen GOPATH einzustellen und das Go-Tool ausführt, wird es sein aktuelles Entwicklungsverzeichnis durcheinander bringen.

@rakyll jedem das seine, wollte nur angeben, was ich und viele andere verwenden. go.googlesource.com/go ist in /usr/local/go.git auf meinem System ausgecheckt.

Wie viele Leute verwenden bereits GOPATH=$HOME/gocode? Es scheint mir nicht viele. Das deutet darauf hin, dass es die falsche Standardeinstellung ist.

Für die Aufzeichnung verwende ich GOPATH=$HOME , aber ich war der Meinung, dass dies zu umstritten wäre und das Ziel dieses Vorschlags, die Erfahrung für den neuen Benutzer zu verbessern, beeinträchtigen würde.

@freeformz , ich denke, wir müssen uns nicht um die vorhandenen kanonischen Pfade außerhalb von $HOME kümmern. Der Standard für GOPATH wird irgendwo in $HOME sein und die minimale Anforderung sollte sein, dass es nicht mit einem kritischen existierenden Pfad kollidiert.

$HOME/gocode klingt für mich fremd, aber es könnte eine sehr gute Wahl sein.

Der Punkt ist, dass es weniger wichtig ist, was der Standard ist, nur dass es einen gibt.

Es spielt keine Rolle, was die Standardeinstellung ist, denn das Festlegen dieser Standardeinstellung wird im Wesentlichen dazu führen, dass jeder, der neu bei Go ist, in einigen Jahren arbeitet.

Der go-Befehl gibt sich alle Mühe, nicht verwirrt zu werden, wenn GOPATH=$GOROOT explizit ist; Ich bin sicher, dass die gleiche Logik auch auf meine implizite Einstellung angewendet werden kann. Ich mache mir also keine allzu großen Sorgen, $HOME/go aus Versehen zu zerstören.

Ich frage mich immer noch, ob wir anstelle eines festen Standardwerts die Eltern des aktuellen Verzeichnisses automatisch durchsuchen sollten, um herauszufinden, wo GOPATH ist. Dies ist, was viele Quelltools heutzutage tun (zum Beispiel jedes Versionskontrollsystem), also ist es ein Konzept, das die Leute verstehen würden. Und es zwingt sie nicht, einen einzigen Verzeichnisnamen zu verwenden oder nur einen GOPATH-Arbeitsbereich zu haben. Aber wir könnten diese Diskussion genauso gut über das ursprüngliche Thema führen.

@rsc Ich würde es lieben, dass der Standard GOPATH=$HOME weil das bedeutet, dass $GOPATH/bin in ihrem Pfad liegt (zumindest auf den meisten Linux-Distributionen, bei Darwin bin ich mir nicht sicher).

$GOPATH=$HOME/go ist auch eine gute Wahl und diejenigen, die den Quellcode des Compilers dort ausgecheckt haben, werden GOPATH=something else bereits gesetzt haben, so dass keine Konfliktgefahr besteht.

Um es klar zu sagen, ich habe nicht versucht, leichtfertig zu sein, als ich sagte

Der Punkt ist, dass es weniger wichtig ist, was der Standard ist, nur dass es einen gibt.

Der Versuch, das Ziel dieses Vorschlags zu betonen, besteht darin, das go-Tool einen Standardwert für $GOPATH wenn einer nicht bereitgestellt wird, da dies für so viele Neulinge in der Sprache eine ständige Quelle für Verwirrung und Frustration ist.

Ich bin am Auto-Sniffing interessiert, weil es bei einem wichtigen Anwendungsfall fehlschlägt, nämlich:

1. Ich habe Go installiert, ich habe die Go-Installationsdokumentation nicht wirklich gelesen, sondern nur den Anweisungen in der README-Datei des Repos gefolgt, in der brew install go
2. Ich habe go get github.com/thething/theproject
3. Jetzt erhalte ich eine Fehlermeldung, dass $GOPATH nicht gesetzt wird. Was ist das? Ich wollte nur dieses Programm ausführen, über das jemand getwittert hat!

Ein Standardwert von GOPATH=$HOME/go SGTM, vorausgesetzt, wir entscheiden uns für einen Standard und nicht für einen automatischen Sniffing-Ansatz.

Der go-Befehl gibt sich alle Mühe, nicht verwirrt zu werden, wenn GOPATH=$GOROOT explizit ist; Ich bin sicher, dass die gleiche Logik auch auf meine implizite Einstellung angewendet werden kann.

Klingt gut.

bei Darwin bin ich mir nicht sicher

Nicht auf Darwin.

Wenn dies für Neulinge ist, würde ich von GOPATH=$HOME abraten, da dies drei Verzeichnisse in ihrem Heimatverzeichnis erstellen würde, anstatt nur eines. Ich bin nicht scharf auf Software, die mein Heimverzeichnis über das notwendige Maß hinaus verschmutzt.

@mvdan Ich verstehe und Ihre Reaktion war, warum ich GOPATH=$HOME .

Wenn _ich_ mein GOPATH auf $HOME möchte, steht mir diese Option weiterhin zur Verfügung und ich müsste keine Änderungen vornehmen, sollte dieser Vorschlag für Go 1.8 angenommen werden.

@davecheney

Standardwert ist der Wert GOPATH=$HOME/gocode

Unter Windows gibt es keine Standardvariable HOME. Was schlagen Sie unter Windows vor?

Ich würde es lieben, dass der Standard GOPATH=$HOME ist, weil das bedeutet, dass $GOPATH/bin in ihrem Weg ist

Ich mache mir immer Sorgen, $GOPATH/bin in meinem PATH zu haben. go get installiert dort die Programme anderer Leute. Wollen wir wirklich, dass neue Go-Benutzer zufällige Programme aus dem Internet irgendwo in ihrem PFAD installieren?

Alex

Ich bin kein erfahrener Windows-Benutzer, aber ich gehe davon aus, dass es eine Vorstellung von einem Basispfad gibt, in dem Dokumente und Einstellungen gespeichert werden. Nehmen Sie zum Zweck dieser Diskussion an, dass ich über diesen Pfad im Kontext von Windows-Benutzern spreche.

Wenn kein solcher Pfad existiert, nehmen Sie an C:/gocode.

In Bezug auf meinen Kommentar zu GOPATH=$HOME, obwohl dies meine persönliche Präferenz ist und bleiben wird, erkenne ich an, dass dies eine umstrittene Option für einen Standardwert ist und als solcher nicht als vorgeschlagener Wert vorgeschlagen wurde.

Die automatische Erkennung birgt Gefahren. Ich habe vor einiger Zeit mit dem Prototyping begonnen, aber es hat sowohl das Go-Tool als auch die Benutzererfahrung erheblich komplexer gemacht.

Ich bin nicht auf dem Laufenden darüber, was mit der Paketverwaltungs-Arbeitsgruppe passiert ist, aber ich kann mir eine nicht allzu ferne Zukunft vorstellen, in der GOPATH vollständig eliminiert wird.

Das heißt, selbst wenn GOPATH irgendwann in naher Zukunft verschwindet, kann es immer noch sinnvoll sein, einen Standardwert festzulegen. Wenn wir glauben, dass GOPATH wahrscheinlich verschwinden wird, spielt es keine große Rolle, worauf wir es einstellen.

Nach dem, was ich oben gelesen habe, gibt es einen Konsens, dass:

1. Standardmäßig ist GOPATH=$HOME zu invasiv.
2. Der Standard sollte irgendwo die Zeichenfolge go (wahrscheinlich als Präfix).

Ich mache mir keine Sorgen, dass GOPATH ein Klon des Haupt-Go-Repos ist (dh GOPATH == GOROOT). Leute, die sich das Go-Repo ansehen, haben wahrscheinlich ein GOPATH-Set. Das go-Tool würde den Konflikt ohnehin erkennen, wie es heute der Fall ist.

Vor diesem Hintergrund wäre die prägnanteste Standardeinstellung $HOME/go , was meiner Meinung nach ziemlich vernünftig ist.

Ich gehe davon aus, dass es eine Vorstellung von einem Basispfad gibt, in dem Dokumente und Einstellungen gespeichert werden.

Ich kenne so etwas nicht. Vielleicht kommentieren andere Windows-Benutzer hier.

Wenn kein solcher Pfad existiert, nehmen Sie an C:/gocode.

Sie möchten stattdessen C:gocode.
Dinge in das Stammverzeichnis von C:\ zu legen, klingt für mich nicht richtig. Würden Sie empfehlen, GOPATH unter Linux auf /gocode zu setzen?
Aber da das Windows-Installationsprogramm Go bereits in C:go installiert, ist C:gocode für GOPATH zumindest konsistent.

Alex

Aber da das Windows-Installationsprogramm Go bereits in C:go installiert, ist C:gocode für GOPATH zumindest konsistent.

GOPATH sollte nicht für jeden Benutzer bereitgestellt werden? Um dasselbe wie UNIX zu sein, denke ich, %USERPROFILE%\gocode .

Go+ Umfrage unter https://goo.gl/xAsgEj

nachdem ich lange so etwas wie $HOME/go-programme benutzt habe, habe ich GOPATH auf $HOME umgestellt. Also ich habe jetzt folgende Struktur:

$HOME/bin
$HOME/Paket
$HOME/src/
$HOME/src/github.com/user/some_github_project
$HOME/src/some_project

Diese Struktur ist allgemeiner und kann auch für die Verwendung mit anderen Sprachen oder Projekten und mit github verwendet werden. zum Beispiel habe ich $HOME/src/talks (lesen Sie es home/sources/talks für Markdown-Dateien) oder andere Projekte in einigen Sprachen (wie $HOME/src/github.com/user/html), aber auch Quellen und ich habe eine Platz für viele Projektquellen mit oder ohne Github-Korrespondenz.

bin oder pkg kann als unordentlich angesehen werden, aber ich denke, es ist nicht so nervig. Es ist unübersichtlicher, viele Quellordner für Leute zu haben, die mehrere Sprachen verwenden.

Aus meiner Sicht ist also $HOME der beste Ort für GOPATH.

Ich verwende $HOME/gocode als GOPATH.
Ich bin gegen $HOME/go, da Sie manchmal kein Root-Recht haben und Go in Ihrem Home-Verzeichnis installieren müssen. In einem solchen Fall denke ich, dass $HOME/go das Beste für GOROOT wäre.
Wir sollten also etwas anderes als $HOME/go als GOPATH verwenden.

@hnakamur Als ich Go manuell installierte (jetzt mit Ubuntu Make), habe ich es in $HOME/bin/go-${go_version} abgelegt (mit einem Symlink von $HOME/bin/go zu $HOME/bin/go-$ {version}/bin/go, also musste ich meinen $PFAD nicht bearbeiten)

@tbroyer Es ist eine Nische. Ich denke, die meisten Benutzer möchten keine zusätzliche Konfiguration oder Einstellungen. Meiner Meinung nach wird ~/bin verwendet, um bereits eigene Skripte oder Binärdateien zu erstellen (wie ich). Und ich denke, ~/bin (~/src, ~/pkg) macht es schwierig, Go-Binärdateien zu entfernen.

Ich verwende $HOME für meinen GOPATH.
Warum GOPATH automatisch setzen, warum nicht eine Warnung mit guten Informationen ausgeben, wie man es setzt, wenn GOPATH nicht existiert?

Warum GOPATH automatisch setzen, warum nicht eine Warnung mit guten Informationen ausgeben, wie man es setzt, wenn GOPATH nicht existiert?

Das Problem ist nicht, dass die Leute (größtenteils) nicht wissen, wie man eine Umgebungsvariable setzt, sondern dass es sich selbst dann schlecht anfühlt, durch die Reifen springen zu müssen, um mit Go zu beginnen. Die Möglichkeit, Go sofort nach der Installation mit vernünftigen Standardeinstellungen zu verwenden, macht die Erfahrung so reibungslos wie möglich und bedeutet, dass wahrscheinlich mehr Leute Go nach dem Herunterladen tatsächlich ausprobieren, anstatt auf eine Straßensperre zu stoßen, ihren Schwung zu verlieren und zu entscheiden, dass es sich nicht lohnt, sich damit herumzuschlagen.

Ich neige dazu, Chris und Andrew zuzustimmen: Wenn es einen Standard-GOPATH geben soll, sollte es nur $HOME/go sein, nicht gopath oder gocode. _Die meisten_ Benutzer haben dort keine Go-Distribution ausgecheckt (und jeder, der es heute tut, setzt bereits GOPATH, also wird sie das nicht stören). Die Standardeinstellung muss für neue Benutzer sinnvoll sein, nicht für fortgeschrittene, und für die meisten Benutzer ist $HOME/go sehr sinnvoll.

Jaana äußerte Bedenken, dass der go-Befehl verwirrt werden könnte, wenn $HOME/go zufällig eine Go-Distribution ist, aber der go-Befehl prüft bereits auf versehentliches GOPATH=$GOROOT. Ob dies der Fall ist, lässt sich leicht überprüfen, wenn GOPATH ebenfalls implizit gesetzt ist. Tatsächlich wäre es auch einfach, den Check zu erweitern, um beispielsweise nach $HOME/go/src/cmd/go/alldocs.go zu suchen, um Verwirrung zu vermeiden, selbst wenn GOROOT!=$HOME/go aber $HOME/go es tut eine Go-Distribution enthalten.

$HOME/go ist keine gute Option für GOPATH. Lassen Sie uns eine einfache Verhaltensübung machen ... neue Benutzer können die Standardeinstellung leicht als Best Practice betrachten. Sagen wir, ich bin ein neuer Benutzer, warum sollte ich die Standardeinstellungen als eine schlechte Sache betrachten? Darüber hinaus ist die einfachste (und beste?) Methode, Golang zu installieren, indem Sie in $HOME entpacken, da der Compiler bei dieser Methode immer auf der neuesten Version ist und keine Root-Rechte benötigt, sodass Sie leicht davon ausgehen können, dass viele Benutzer go-Compiler haben werden in $HOME/go. Warum sollte ich den Compiler in /usr/local verschieben, wenn ich es einfach nicht kann?
Darüber hinaus können sie Projekte erstellen und Projekte in diesem Ordner klonen. Sie werden also einen unordentlichen Ordner haben und mit ein wenig Nachlässigkeit können sie ihren Projektordner mit einer neuen Golang-Neuinstallation einfach löschen.
Außerdem haben Windows-Benutzer standardmäßig c:go.

Ich mag $HOME/gopath. Es sagt, was es ist.
Das erste Ergebnis bei Google für "gopath" ist die richtige Seite.

Wenn eine Vorgabe übernommen wird, könnte dann eine func GOPATH() string Funktion zu runtime hinzugefügt werden? Im Moment kann man os.Getenv() , aber mit einem Standard wird es nicht so einfach sein.

@btracey , GOPATH ist eine Liste, kein einzelner Wert. Verwenden Sie filepath.SplitList . Außerdem ist GOPATH keine Funktion der Laufzeit. Es betrifft nur cmd/go .

Aus Gründen der Abwärtskompatibilität müssten wir wahrscheinlich GOPATH im Prozess setzen.
Umgebung, wenn keine festgelegt ist.

Am 30. September 2016 um 08:10 Uhr, Brendan Tracey [email protected]
schrieb:

Wenn eine Vorgabe übernommen wird, könnte eine func GOPATH() String-Funktion hinzugefügt werden
zur Laufzeit? Im Moment kann man os.Getenv() verwenden, aber mit einem Standard it
wird nicht so einfach sein.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -250605418 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

Du hast recht @bradfitz. Die von @adg vorgeschlagene

Dies ist eine interessante Falte. Ich kann sehen, dass dies derzeit fehlschlägt, wenn nein
GOPATH gesetzt ist, aber auch wenn GOPATH mehrere Werte enthält, und dann
Es gibt Fälle, in denen die Anwendung auf einem Computer erstellt und auf einem bereitgestellt wird
Ein weiterer.

Ich möchte diese Verwendung von GOPATH nicht ablehnen, ich verstehe den Schmerz von
in der Lage zu sein, Support-Dateien für Ihre Anwendung zu finden, aber ich möchte
um zu verstehen, wie weit verbreitet diese Verwendung ist und wie die aktuelle
Implementierungen befassen sich mit den Problemen, die ich oben hervorgehoben habe.

Am Freitag, 30. September 2016, 08:35 Uhr schrieb Brendan Tracey [email protected] :

Du hast recht @bradfitz https://github.com/bradfitz. Die Lösung
vorgeschlagen von @adg https://github.com/adg würde alle meine Zwecke erfüllen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -250611813 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

Meine Nutzung ist nicht die normale. Ich betreibe wissenschaftliche Forschung und finde es sehr effektiv, nicht nur gopath/src und gopath/bin , sondern auch gopath/data und gopath/results . Dies macht es einfach, die Quelldateien auf ein neues System zu kopieren, ohne auch die (Gigabytes an) Ergebnisdateien kopieren zu müssen. Das neue System (z. B. ein Cluster) generiert neue Ergebnisdateien, und ich kann diese Ergebnisse an einen zentralen Ort kopieren. Es ist wirklich einfach, gopath = os.Getenv("GOPATH") zu sagen und eine Datei in etwa filepath.Join(gopath, "results", "projectname", result.json) speichern.

Dankeschön. Um das klarzustellen, wollte ich nicht andeuten, dass Ihre Verwendung falsch war oder
falsch, ich wollte nur diese Verwendung von GOPATH in Bezug auf die verstehen
Einschränkungen, die ich hervorgehoben habe.

Am Fr, 30 Sep 2016, 09:09 schrieb Brendan Tracey [email protected] :

Meine Nutzung ist nicht die normale. Ich forsche wissenschaftlich und habe herausgefunden
es ist sehr effektiv, nicht nur gopath/src und gopath/bin zu haben, sondern auch
gopath/data und gopath/results. Dies macht es einfach, die Quelle zu kopieren
Dateien auf ein neues System übertragen, ohne die (Gigabytes an)
Ergebnisdateien. Das neue System (z. B. ein Cluster) erzeugt neue Ergebnisdateien,
und ich kann diese Ergebnisse an einen zentralen Ort kopieren. Es ist ganz einfach
sagen Sie dann gopath = os.Getenv("GOPATH") und speichern Sie eine Datei wie filepath.Join(gopath,
"results", "projectname", result.json).

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -250617618 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

Daumen hoch hier, wenn du derzeit GOPATH=$HOME/.go

@davecheney nicht beleidigt, wollte nur genügend Kontext bereitstellen, um nützlich zu sein.

Lassen Sie uns bitte die Verwendung von GOPATH zum Auffinden von Supportdateien aus dieser Diskussion aufgeben.

(GOPATH soll eine Kompilierzeit-Einstellung sein, keine Laufzeit-Einstellung. Ich weiß, dass Leute diese manchmal verwischen und GOPATH verwenden, um verknüpfte Dateien zur Laufzeit zu finden, aber ich denke nicht, dass wir das fördern oder machen sollten Es ist einfacher zu tun. Wir brauchen eine bessere Geschichte für Support-Dateien im Allgemeinen, aber das sollte ein separates Thema sein.)

Bezieht sich auf das Auffinden verknüpfter Dateien zur Laufzeit: #12773

Es tut mir leid, die Diskussion noch einmal zu verschmutzen @randall77 , #12773 ist schwieriger zu verwenden, als dieses Problem direkt zu umgehen. Spezifischer Code, der eine Datei benötigt (oder eine Datei speichern soll), kann sich viel bewegen, und ich möchte einen festen Platz für Ein- und Ausgaben, der unabhängig von (und getrennt von) Refactoring lebt.

Bei diesem Problem geht es um einen möglichen Standardwert von GOPATH. Es geht _nicht_ um alternative Verwendungen von GOPATH.

Wenn die Zielbenutzer für diese Änderung nur diejenigen sind, die es gerade wollten
Installieren Sie ein neues Programm, das in Go geschrieben wurde, und nicht diejenigen, die es tatsächlich wollen
schreiben Sie Go, und was ist, wenn wir Go in einem Pro-Benutzer-Verzeichnis in klonen lassen?
$TMPDIR, und belassen Sie die Binärdatei bei $PWD, wenn $GOPATH nicht gesetzt ist? (Offensichtlich
Dies ist nur für go get import.path/for/a/command sinnvoll, wenn es nicht a . ist
Befehl, go get sollte fehlschlagen, ohne dass $GOPATH gesetzt ist)

Für Außenstehende ist dies sehr sinnvoll, genau wie wget eine Datei.

Sobald der Benutzer mit dem Schreiben von Go-Code beginnen möchte, sollte er lernen, wie man
GOPATH richtig.

Ich bin gegen $HOME/go, da Sie manchmal kein Root-Recht haben und Go in Ihrem Home-Verzeichnis installieren müssen. In einem solchen Fall denke ich, dass $HOME/go das Beste für GOROOT wäre.

Wenn Sie ein Linux-System verwenden, würde ich argumentieren, dass $HOME/.local/opt/go der beste Ort für $HOME/.local/opt/go sein könnte, nicht $HOME/go, je nachdem, wie Sie den Zweck von $HOME/.local interpretieren , da nur $HOME/.local/share (erscheint als Spiegel /usr/local/share) in der XDG Base-Verzeichnisspezifikation definiert ist: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest. html.

Man könnte auch argumentieren, dass der beste Standard für GOPATH / GOBIN (unter Linux) sein sollte:
GOPATH=$XDG_DATA_HOME/go oder $HOME/.local/share/go
GOBIN=$HOME/.local/bin

Aber das ist für neue Benutzer wahrscheinlich nicht am einfachsten zu verstehen? Und es würde auch unklar lassen, was der beste Ansatz unter Windows ist. $HOME/go und $USERPROFILE/go erscheinen pragmatisch.

Bitte, _bitte_ lasst uns diesen Thread nicht in eine Diskussion über kanonische Linux-Pfadnamen und Speicherorte verwandeln. Es ist nicht produktiv, und ich habe das Gefühl, dass diese Diskussion bereits ziemlich weit von Dave Cheneys ursprünglichem Beitrag abgewichen ist.

Ich bin mir auch nicht sicher, ob der tatsächliche absolute Standort so wichtig ist. Ich denke, dieser Thread muss sich nur entscheiden: "Wollen wir einen Standard-Gopath?" (klingt, als wäre das ein mehr oder weniger überwältigendes Ja) und "sollte es systemweit oder lokal für den Benutzer freigegeben werden" (bisher drehten sich die meisten Diskussionen um lokal). Danach kann jeder, der es umsetzt, $HOME/gocode oder $HOME/go oder /usr/share/go/ auswählen oder was immer er möchte, der demjenigen, der die PR überprüft, vernünftig erscheint, und die Dinge werden wahrscheinlich weiterhin ziemlich in Ordnung sein.

Ich denke, ein systemweites GOPATH ist aufgrund von Berechtigungsproblemen kein Starter.

​

Der systemweite Pfad ist zum Guten oder zum Schlechten GOROOT, das verteilt
wie Debian verwendet, um "systemweite" Pakete zu installieren, zum Guten oder zum Zweck
schlechter.

Ein systemweiter GOPATH ist nicht Gegenstand dieses Vorschlags, dieser Vorschlag
empfiehlt einen Pfad, der vom Wert des angemeldeten Benutzers abgeleitet wird.

Am Di, 4 Okt 2016, 08:52 schrieb Andrew Gerrand [email protected] :

Ich denke, ein systemweites GOPATH ist aufgrund von Berechtigungsproblemen kein Starter.

​

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -251238251 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

Bitte lassen Sie uns diesen Thread nicht in eine Diskussion über kanonische Linux-Pfadnamen und Speicherorte verwandeln. Es ist nicht produktiv

Gut, lass uns nicht. Mein Hauptpunkt war wirklich, auf einen weiteren Grund hinzuweisen, dass $HOME/go als GOPATH-Standard wahrscheinlich nicht problematisch ist, da es wahrscheinlich sowieso nicht der "idiomatischste Linux"-Pfad für lokale Benutzerinstallationen von Go (auch bekannt als GOROOT) ist.

Abgesehen davon glaube ich, dass es bereits diskutiert wurde , XDG_CACHE_HOME für einen Standard-GOPATH zu verwenden, weshalb ich XDG_DATA_HOME erwähnt habe - obwohl ich nicht weiß, welche Rolle die Autoren des verlinkten Dokuments spielen oder wie "offiziell" es ist .

$HOME/arbeit.......

@adg @quentinmit @rsc Was sind die nächsten Schritte für diesen Vorschlag?

Würde mich sehr freuen, wenn hier etwas passiert. es ist ein häufiger Schmerzpunkt in meinem Unterricht. Jede Vorgabe (sogar $home/go, mit der ich nicht einverstanden bin :) ) ist besser als keine.

$HOME/go wird es sein. Es gibt keine einzige beste Antwort, aber dies ist kurz und bündig, und es kann nur ein Problem sein, diesen Namen zu wählen, wenn $HOME/go bereits existiert, was nur für Experten glücklich ist, die go bereits installiert haben und GOPATH verstehen.

Wer will die Arbeit machen?

Daran arbeite ich auf jeden Fall gerne mit.

@campoy , kannst du das <= diesen Freitag machen?

Ich würde sagen, ja @bradfitz . Es hört sich nicht nach einer großen Menge an Code an, die erstellt werden muss.
Ich kann morgen anfangen.

Update: Ich habe mir das kurz angeschaut und bereits Code geschrieben, werde einige Tests hinzufügen und später heute eine Änderung senden

Das ist großartig Jungs! 👍

@robpike hast du auch meinen alternativen Vorschlag in #17271 in Betracht gezogen? Ich würde gerne verstehen, warum dieser Vorschlag als besser erachtet wurde

Es ist keine gute Idee, die Namen des Go-Installationsverzeichnisses und des Arbeitsbereichsverzeichnisses gleich zu lassen, dh go weil:

1) Es ist für einen naiven Benutzer sehr einfach, den Arbeitsbereich zu beschädigen/verschmutzen, wenn der Benutzer tar -xzf go$VERSION.$OS-$ARCH.tar.gz im Home-Verzeichnis tut

2) Die Standarderfahrung eines neuen Benutzers, wenn er nicht unter /usr/local installiert (möchte nicht als Root installieren), wird nicht reibungslos sein, da dies der Ablauf ist:
go$VERSION.$OS-$ARCH.tar.gz . herunterladen
tar -xzf go$VERSION.$OS-$ARCH.tar.gz --> installiert in $HOME/go
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something --> wirft cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

@krishnasrinivas Ich verstehe, dass, wenn GOROOT=$HOME/go , diese Standardeinstellung entweder nicht stattfindet oder einen go Fehler macht, da GOROOT und GOPATH nicht gleich sein können. In solchen Fällen wird, wie bereits erwähnt, erwartet, dass der Benutzer in der Lage ist, seine eigenen GOPATH .

@mvdan richtig, für neue Benutzer, die keine Root-Rechte für die Installation verwenden möchten (und daher eine hohe Wahrscheinlichkeit, Go in ~/go zu installieren), machen wir es nicht einfacher, die Dinge zum Laufen zu bringen, da sie dies explizit tun müssen setze GOPATH auf etwas anderes. Dies kann leicht behoben werden, wenn der Standard-GOPATH entweder ~/gopath oder ~/gocode ist

Wenn neue Benutzer bei einer Nicht-Root-Installation die Voreinstellung GOPATH=~/go nutzen müssen, muss die Installationsdokumentation etwas komplizierter gemacht werden, indem die Benutzer explizit aufgefordert werden, die Option tar -C zu verwenden, um sie nicht zu installieren bei ~/go

@rasky Ich betrachte #17271 und diesen Vorschlag als orthogonal. Die Auflösung dieses Vorschlags ist ein einfacher Sieg, der uns nicht in eine bestimmte Richtung drängt. Ich werde dieses Thema weiter ausführen.

Ich stimme @krishnasrinivas zu. Ich hatte keine Root-Berechtigungen, also entpackte ich Go to $HOME/go. Ich habe auch mein $GOPATH=$HOME/gowork gesetzt.

@krishnasrinivas @joegrasse Es gibt keine perfekte Lösung. Es ist einfach, GOPATH selbst festzulegen, und ich gehe davon aus, dass dies die meisten Leute tun werden. Die Frage hier ist, was wir für die Leute tun sollten, die neu bei Go sind. Dies sind im Allgemeinen keine Personen, die ihre eigene Go-Distribution an benutzerdefinierten Standorten installieren. Leute, die wissen, wie man Go an einem benutzerdefinierten Ort installiert, kann herausfinden, wie man GOPATH .

Denken Sie statt an eine Klasse neuer Programmierer, die vorinstallierte Go-Distributionen verwenden. Wir möchten, dass sie mit dem Schreiben von Go-Code beginnen können. Wir möchten nicht, dass der erste Schritt lautet: "Das ist eine Umgebungsvariable. So legen Sie eine fest. Legen Sie jetzt GOPATH ." Diese Schritte haben nichts mit Go als solchem ​​zu tun.

Auch hier gibt es keine perfekte Lösung, aber es scheint ratsam, etwas auszuwählen.

@ianlancetaylor Ich stimme

@ianlancetaylor GOPATH=$HOME/gopath ist aus den oben genannten Gründen ein besserer Standard als GOPATH=$HOME/go.

Ich glaube nicht, dass der aktuelle Name ein Problem ist - wenn Sie wissen, wie Sie PATH für einen benutzerdefinierten go/bin-Speicherort unter Ihrem Homedir festlegen, wissen Sie, wie Sie GOPATH festlegen.

@joegrasse @krishnasrinivas Sehen Sie sich " An einem benutzerdefinierten Speicherort installieren " an.

Wenn Sie aus Gründen von Berechtigungen oder aus anderen Gründen an einen anderen Ort als /usr/local/go enttarnen, ist es notwendig, auch GOROOT zu setzen oder aus dem Quellcode zu kompilieren.

Solange dies der Fall ist, hat die Verwendung von $HOME/gopath usw. keinen Vorteil gegenüber dem vorgeschlagenen $HOME/go.

Sie gehen davon aus, dass neue Benutzer es vorziehen, von der tar.gz zu installieren. Ich kann nein zitieren
Zahlen, aber glauben Sie, dass Ihre Antwort auf Linux-Installationen basiert, die
sind das drittbeliebteste Installationsziel für go.

Am Dienstag, 25. Oktober 2016, 20:28 Uhr Krishna Srinivas [email protected]
schrieb:

@mvdan https://github.com/mvdan richtig, für Benutzer die nicht wollen
Verwenden Sie Root-Rechte für die Installation (und daher hohe Wahrscheinlichkeit der Installation)
Gehen Sie rein ~/go) wir machen es nicht einfacher, die Dinge zum Laufen zu bringen, als
sie müssen GOPATH explizit auf etwas anderes setzen. Das kann sein
leicht behoben, wenn GOPATH entweder ~/gopath oder ~/gocode ist

Bei Nicht-Root-Installation, wenn neue Benutzer den Standard nutzen müssen
GOPATH=~/go dann muss die Dokumentation etwas komplizierter gemacht werden
indem die Benutzer explizit aufgefordert werden, die Option tar -C zu verwenden, um sie nicht unter zu installieren
~/geh

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -255984498 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

Die Dokumente müssen auch alle aktualisiert werden. Das ist wohl der Großteil der Arbeit.

Am 25. Oktober 2016 um 10:14 Uhr, Francesc Campoy [email protected]
schrieb:

Ich würde sagen, ja. Es hört sich nicht nach einer großen Menge an Code an, die erstellt werden muss.
Ich kann morgen anfangen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -255892314 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

Ich würde sagen, ja. Es hört sich nicht nach einer großen Menge an Code an, die erstellt werden muss.
Ich kann morgen anfangen.

Am Montag, 24. Oktober 2016 um 16:05 Uhr Brad Fitzpatrick [email protected]
schrieb:

@campoy https://github.com/campoy , kannst du es vor <= diesen Freitag machen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -255890668 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

Bei Bedarf kann ich mit den Dokumenten helfen. Das einzige Problem ist, dass das aktuelle Material ausschließlich von GOPATH als Bezugspunkt abhängt. Zum Beispiel,

"Oder, da Sie $GOPATH/bin zu Ihrem PATH hinzugefügt haben, geben Sie einfach den Binärnamen ein:"

oder

"Paket unter GOPATH erstellen, mkdir -p $GOPATH/src/github.com/user/hello"

Ohne sich mit GOPATH zu beschäftigen und zu lernen, was es ist, ist es fast unmöglich, in Go etwas anderes zu erledigen, als Pakete von Drittanbietern zu besorgen. Wenn wir den Standardpfad über go env melden können, wäre das in den Dokumenten leicht zu finden.

Vielleicht könnte stattdessen $HOME/go/... ersetzt werden (oder das Äquivalent unter Windows)?

Da Sie $HOME/go/bin zu Ihrem PATH hinzugefügt haben (oder $GOPATH/bin wenn GOPATH gesetzt ist)...

Vielleicht könnte die Dokumentation irgendwann erwarten, dass Einzelpersonen nicht nur die Umgebungsvariable PATH setzen, sondern auch GOPATH auf $HOME/go setzen. Obwohl redundant, bereitet es den Benutzer auf spätere Verweise auf GOPATH vor.

Die anfängliche Dokumentation könnte den Standard annehmen und Umgebungsvariablen überhaupt nicht erwähnen.

Sie gehen davon aus, dass neue Benutzer es vorziehen, von der tar.gz zu installieren. Ich kann nein zitieren
Zahlen, aber glauben Sie, dass Ihre Antwort auf Linux-Installationen basiert, die
sind das drittbeliebteste Installationsziel für go.

Sie haben Recht, meine Meinung ist gegenüber Linux-Installationen voreingenommen. Ich kann sehen, dass für neue Benutzer, die go in /usr/local installieren, ~/go möglicherweise ein besser erkennbarer Verzeichnisname ist als ~/gopath

Die anfängliche Dokumentation könnte den Standard annehmen und nicht erwähnen
Umgebungsvariablen überhaupt?

Ja, hoffentlich kann die ganze ablenkende Debatte über die Einstellung von GOPATH verschoben werden
zu einem Anhang der Installationsdokumentation, genau wie bei GOROOT
zur Zeit.

Am Mittwoch, 26. Oktober 2016, 06:01 schrieb Nathan Youngman [email protected] :

Vielleicht könnte stattdessen $HOME/go/... ersetzt werden (oder das Äquivalent auf
Fenster)?

Da Sie $HOME/go/bin zu Ihrem PATH hinzugefügt haben (oder $GOPATH/bin, wenn GOPATH
einstellen)...

Vielleicht könnte die Dokumentation irgendwann erwarten, dass Einzelpersonen dies nicht tun
Setzen Sie nur die Umgebungsvariable PATH, sondern auch GOPATH auf $HOME/go.
Obwohl redundant, macht es die spätere Dokumentation klar.

Die anfängliche Dokumentation könnte den Standard annehmen und die Umgebung nicht erwähnen
überhaupt Variablen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -256142424 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

Die anfängliche Dokumentation könnte den Standard annehmen und Umgebungsvariablen überhaupt nicht erwähnen.

SGTM

Es gibt zwei Arten von Go-Benutzern:

• Benutzer, die sich einfach bestehende Pakete holen
• Benutzer, die Go-Entwickler sind

Standardmäßig behebt GOPATH den Fall für die erste Gruppe. Wir können weiterhin GOPATH-bezogene Anweisungen für die Entwicklerdokumente aufbewahren. Die Installation sollte das Setzen von GOPATH überhaupt nicht mehr erwähnen müssen oder wir können einen Anhang haben, wie @davecheney erwähnt.

Als jemand, der ~/bin/go wegen Go umbenennen musste, schlage ich vor, dass unabhängig von der Standardeinstellung, wenn es bereits existiert, eine .dot-Datei enthalten sein muss, um anzuzeigen, dass es wirklich Gos ~/go ist. Wenn ~/go nicht existiert, kann go es erstellen, die .dot-Datei erstellen und zukünftige Läufe können es finden. Wenn ich GOPATH explizit auf ~/go setze, ist keine .dotfile erforderlich, da kein Standardwert verwendet wird.

Die Punktdatei existiert. Es ist das Verzeichnis src/ in $HOME/go.

Am Mittwoch, 26. Oktober 2016, 07:59 Uhr schrieb RalphCorderoy [email protected] :

Als jemand, der wegen Go ~/bin/go umbenennen musste, schlage ich gerne vor
dass, was auch immer die Standardeinstellung ist, wenn es bereits existiert, dann muss es a . haben
.dotfile darin, um anzugeben, dass es wirklich Gos ~/go ist. Wenn ~/go nicht existiert,
go kann es erstellen, die .dotfile erstellen und zukünftige Läufe können es finden. Wenn ich
Setzen Sie GOPATH explizit auf ~/go, dann ist keine .dotfile erforderlich, da nein
Standardwert wird verwendet.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -256173981 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

CL https://golang.org/cl/32019 erwähnt dieses Problem.

Auch wenn einige Programmierer Umgebungsvariablen nicht kennen, sie
sollten zumindest mit _variablen_ vertraut sein. Ich denke, wir werden brauchen
etwas verwenden, um die Position eines Arbeitsbereichs in den Dokumenten zu beschreiben, und
die Zeichenfolge $GOPATH könnte es genauso gut sein.

Am 26. Oktober 2016 um 06:24 Uhr, Jaana Burcu Dogan [email protected]
schrieb:

Die anfängliche Dokumentation könnte den Standard annehmen und die Umgebung nicht erwähnen
Variablen überhaupt.

SGTM

Es gibt zwei Arten von Go-Benutzern:

• Benutzer, die sich einfach bestehende Pakete holen
• Benutzer, die Go-Entwickler sind

Standardmäßig behebt GOPATH den Fall für die erste Gruppe. Wir können noch behalten
GOPATH-bezogene Anweisungen für die Entwicklerdokumente. Die
Installation sollte das Setzen von GOPATH gar nicht mehr erwähnen müssen oder wir
kann einen Anhang als @davecheney haben https://github.com/davecheney
erwähnt.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -256149104 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

Danke ist die Absicht, bitte sehen Sie sich den ursprünglichen Vorschlag an.

Tatsächlich können wir jetzt sagen "go get wird die Quelle in einen Ordner herunterladen"
aufgerufen, go/src/github.com/Foo/Bar in Ihrem Home-Verzeichnis"

Am Mittwoch, 26. Oktober 2016, 06:01 schrieb Nathan Youngman [email protected] :

Vielleicht könnte stattdessen $HOME/go/... ersetzt werden (oder das Äquivalent auf
Fenster)?

Da Sie $HOME/go/bin zu Ihrem PATH hinzugefügt haben (oder $GOPATH/bin, wenn GOPATH
einstellen)...

Vielleicht könnte die Dokumentation irgendwann erwarten, dass Einzelpersonen dies nicht tun
Setzen Sie nur die Umgebungsvariable PATH, sondern auch GOPATH auf $HOME/go.
Obwohl redundant, macht es die spätere Dokumentation klar.

Die anfängliche Dokumentation könnte den Standard annehmen und die Umgebung nicht erwähnen
überhaupt Variablen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -256142424 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

Das wäre ein tolles Thema für die letzte Hacktoberfestwoche

Die Punktdatei existiert. Es ist das Verzeichnis src/ in $HOME/go

"src" ist viel zu gebräuchlich, um eine "dies wurde als Standard-GOPATH von Go erstellt"-Punktdatei zu sein.

Was versuchen Sie zu verhindern?

Am Mittwoch, 26. Oktober 2016 um 9:20 Uhr, RalphCorderoy [email protected]
schrieb:

Die Punktdatei existiert. Es ist das Verzeichnis src/ in $HOME/go

"src" ist viel zu gebräuchlich, um ein "dieses wurde als Standard-GOPATH erstellt von
Los" Punktdatei.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -256194536 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$HOME/go wird es sein.

Was wird es für Windows-Benutzer sein?

Alex

Windows-Benutzer verwenden %USERPROFILE%\go , genau wie Docker hier .

@davecheney , ich versuche zu verhindern, was ich vor zwei Stunden gesagt habe: https://github.com/golang/go/issues/17262#issuecomment -256173981

Gehen ist ein gängiges Wort. Ich hatte ein ~/bin/go. Die Leute spielen Go und haben Quellcode, der mit dem Spielen von Go zu tun hat. ~/go standardmäßig zu schnappen, wenn es bereits existiert, nur weil es zufällig src enthält, ist unhöflich. Wenn ~/go nicht existiert, dann kann Go den Namen abrufen, das Verzeichnis erstellen, es mit einer signifikanten Punktdatei als golang stempeln, zB basierend auf dem golang.org Domainnamen.

Das ist das Problem und sowieso eine mögliche Lösung. Auch wenn die Lösung nicht die richtige ist, heißt das nicht, dass das Problem nicht existiert.

Ich stimme $ HOME/group

Vielen Dank.

Können wir den GOPATH-Standard als ~/.gosrc ?

Können wir den GOPATH-Standard als ~/.gosrc ?

Dies wird standardmäßig unter Linux und OS X ausgeblendet und in Windows sichtbar. Was wäre die Motivation, GOPATH zu verstecken?

Die Diskussion über den Wert des Ausfalls fand vor einem Monat statt. Die Entscheidung zu $HOME/go ist gefallen und wird bereits umgesetzt. Wenn wir auf dieses Thema zurückkommen, wird der Thread nur unerträglich lang.

Die Leute spielen Go und haben Quellcode, der mit dem Spielen von Go zu tun hat.

Ich folge dir nicht wirklich, aber da du GOPATH auf gesetzt hast
schon etwas anderes, es wird keine Auswirkungen auf Sie haben.

Am Mittwoch, 26. Oktober 2016 um 9:43 Uhr, RalphCorderoy [email protected]
schrieb:

@davecheney https://github.com/davecheney , ich versuche zu verhindern, was ich
sagte vor zwei Stunden: #17262 (Kommentar)
https://github.com/golang/go/issues/17262#issuecomment -256173981

Gehen ist ein gängiges Wort. Ich hatte ein ~/bin/go. Leute spielen Go und haben Quellcode
mit dem Spielen zu tun. Nabbing ~/go standardmäßig, wenn es bereits existiert, einfach
weil es zufällig src enthält, ist es unhöflich. Wenn ~/go nicht existiert, dann Go
kann den Namen schnappen, das Verzeichnis erstellen, es als Golang mit a . stempeln
aussagekräftige Punktdatei, zB basierend auf dem Domainnamen golang.org.

Das ist das Problem und sowieso eine mögliche Lösung. Auch wenn die Lösung
ist nicht der richtige, das heißt nicht, dass das Problem nicht existiert.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -256199766 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

Hallo @davecheney , Dieses Problem begann damit, dass Sie ~/gocode vorschlugen. Im Laufe der Zeit wurde daraus ~/go. @robpike sagte oben "es kann nur ein Problem sein, diesen Namen zu wählen, wenn $HOME/go bereits existiert, was nur für Experten glücklich ist, die go bereits installiert haben und GOPATH verstehen". Ich denke, wenn man so lange in Golang gehüllt ist, vergisst man kollektiv, wie gebräuchlich ein Wort "go" ist und wie es andere Bedeutungen hat, wie das Brettspiel.

Diese Änderung richtet sich an Go-Neulinge und einige von ihnen könnten ~/go bereits für eine Nicht-Go-Nutzung haben. Ich schlage vor, wenn go kommt, feststellt, dass GOPATH nicht gesetzt ist und kein ~/go existiert, dann kann es es erstellen und den Namen ergreifen. Aber wenn ~/go existiert, sollte es es nur verwenden, wenn es erkennen kann, dass es es in einem früheren GOPATH-losen Aufruf erstellt hat. Ich schlug vor, eine Punktdatei als dieses Flag zu erstellen. Sie sagten, dass ~/go/src als dieses Flag dienen wird. Mein Einwand ist, dass src selbst unter Programmierern nicht ungewöhnlich ist, dh diejenigen, die Go installieren könnten. Eine ungewöhnliche Punktdatei, zB ~/go/.default-gopath, vermeidet diesen potentiellen Konflikt.

Wenn sie ~/go für Go manuell erstellt und go ohne GOPATH ausgeführt haben, wird ~/go nicht verwendet, da die Punktdatei fehlt. Ich denke, dies ist in Ordnung, da sie mit dem Einrichten einer Go-Installation fortfahren und GOPATH festlegen sollten. Sie sind nicht der einfache "Paket installieren, go(1) ausführen"-Fall, der anvisiert wird.

Wenn nichts davon als Problem angesehen wird, ist das in Ordnung. Aber solange Sie sich beschweren, dass Sie meinen Standpunkt nicht verstehen, bin ich dazu verdammt, immer wieder zu versuchen, es zu erklären.

Deshalb habe ich ursprünglich einen anderen Weg vorgeschlagen, mit Robs Vorschlag liegt es jetzt offiziell nicht mehr in meiner Hand.

Vor diesem Hintergrund bin ich froh, dass _a_ Pfad gewählt wurde, da ich dies als den Punkt der Übung sehe.

In Bezug auf Ihre Bedenken empfehle ich Ihnen, https://go-review.googlesource.com/#/c/32019/ zu folgen, wo genau das Thema besprochen wird, das Sie interessiert.

@RalphCorderoy , Ihr Anliegen ist, dass Go-the-Brettspiel-Programmierer ein ~ / go-Verzeichnis für das Hacken von Brettspielen haben?

Rob und Russ sind sehr gegen Dotfiles. Es ist besser, das Problem anzugeben, als die Antwort anzugeben, wenn die Antwort Punktdateien (oder Symlinks) enthält.

@bradfitz , ja, ~/go existiert bereits für Gogame-Spieler und weiter ~/go/src existiert, weil sie Programmierer-Gogame-Spieler sind, sonst würden sie nicht mit Go spielen. (Ich habe zufällig ~/chess/src.)

Die Zusammenfassungslogik von adg https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c scheint in Ordnung zu sein, und ich bin dafür, ~/go zu erstellen, wenn es nicht existiert, aber test -d ~/go/src ist ein flockiger Test für die Verwendung von ~/go, wenn kein GOPATH vorhanden ist.

Wenn es nicht ~/go wäre, sondern etwas Ungewöhnlicheres, wie Daves ursprünglicher Vorschlag, dann wäre es egal. Ich denke, die Umfragen über das, was derzeit verwendet wird, die zeigten, dass ~/go sehr beliebt war, sind nicht allzu hilfreich, wenn die Wähler Go-Programmierer sind, die ausreichend daran interessiert sind, Themen und soziale Medien zu verfolgen.

@RalphCorderoy Ich denke, die Sorgfalt und die doppelte Unterhose, die in CL 32019 entwickelt werden, sind mehr als ausreichend für die potenziellen Unannehmlichkeiten für die kleine Gruppe von Game-of-Go-Programmierern, die Go vor Version 1.8 _nicht_ verwendet haben und _nicht_ eingestellt haben GOPATH _und_ beginnen auch, Go, die Sprache, zu lernen.

Das Go-Tool wird keinen Non-Go-Code löschen oder beschädigen, auf den es stößt, Sie erhalten nur in _wenigen_ Situationen eine etwas verwirrende Meldung. Um dies zu erklären, erstellt das go-Tool den Go-Quellcode nicht am Anfang von $GOPATH/src da sich dieser Code nicht in einem importierbaren Paket befindet. Darüber hinaus ist das andere Ziel dieser Änderung es leichter zu machen , go get , indem einen Standard - Speicherort zu Download - Quelle , um einige Codes, so _if_ gibt es den Spiel-of-go - Quellcode in ~/go/src , die Wahrscheinlichkeit eines Konflikts mit einem Unterverzeichnis, das von einem go gettable-Repository abgeleitet ist, ist sehr gering, und selbst wenn dies passieren würde, würden entweder das go-Tool oder git abbrechen, bevor irgendwelche Daten geändert wurden.

Ich halte die Situation, über die Sie sich Sorgen machen, für sehr unwahrscheinlich und wird durch die obige Erklärung weiter abgemildert.

(Nur ein wahrscheinlich gültiges Argument gegen GOPATH=$HOME ): Wird die Leistung von goimports angesprochen? Ich erinnere mich an etwas über eine .goimport_ignore Datei. Andernfalls könnte die Leistung für beliebte Editoren leiden.

Somit ist GOPATH!=$HOME wahrscheinlich eine kollisionsfreie/nicht verschmutzte Option und sollte performant sein.

@davecheney Nach go get müsste ich ~/go/{bin,src,pkg} ausräumen, und es wäre keine schöne Einführung in Go, wenn ich die Zeile eingefügt hätte, die ich im Internet gefunden habe.

@RalphCorderoy Bitte

@RalphCorderoy Die von Ihnen beschriebene Situation ist selten, und jeder, der Shell-Befehle von einer zufälligen Website .wine im Home-Verzeichnis des Benutzers automatisch erstellt und ändert. Was ist, wenn der Benutzer dort etwas anderes hat? Schließlich ist "Wein" ein Begriff, den wir für ein bestimmtes Getränk verwenden.)

Die Namenskollision zwischen "Go" der Sprache und "Go" dem Brettspiel ist sicherlich verstanden und bekannt. Das Dateisystem ist eine gemeinsam genutzte Ressource, Kollisionen passieren und sind unvermeidlich.

@davecheney , Bitte

Nachdem er den Go-Get-Spew in ~/go aufgeräumt hatte, weil er wüsste, was normalerweise nicht da war, musste er dann recherchieren, um zu sehen, was die Befehle unter $HOME sonst noch gemacht haben, falls mehr Aufräumen war angesagt.

Abmelden

Es tut mir leid, wenn ich Sie beleidigt habe. Ich möchte nicht mehr korrespondieren
mit Ihnen zu diesem Thema. Dankeschön.

Am Freitag, 28. Oktober 2016 um 3:28 Uhr, RalphCorderoy [email protected]
schrieb:

@davecheney https://github.com/davecheney , Bitte hör auf, mir das zu erzählen
change soll mir nicht helfen, da ich kein neuer Go-Benutzer bin. Ich habe
war sich dessen immer bewusst, noch bevor man anfing, darauf hinzuweisen. ich auch
verstehen, dass Ihre Position len(intersect(existing-~/go, GOPATH-less)) ist
zu klein, um besorgniserregend zu sein.

Nachdem er den Go-Get-Spuck in ~/go aufgeräumt hatte, weil er wüsste, was
normalerweise nicht da war, musste er dann recherchieren, um zu sehen, was sonst noch da war
Befehl(e) wurden möglicherweise unter $HOME ausgeführt, falls weitere Aufräumarbeiten erforderlich waren.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/17262#issuecomment -256697043 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

davecheney, Nein, nicht beleidigend. Es macht nur keinen Sinn, immer denselben Boden abzudecken.

Ich frage mich nur – was ist das erwartete Verhalten, wenn $HOME nicht gesetzt ist?

Obwohl ich noch nie an einem System gearbeitet habe, bei dem dies der Fall war, scheint es möglich, dass jemand aus irgendeinem Grund seine Standard-Env-Variablen geändert hat, und dieser Randfall sollte konsequent behandelt werden.

Ich denke, es wertet derzeit $GOPATH='' ; Bedeutet das, dass das aktuelle Arbeitsverzeichnis verwendet wird?

das aktuelle Arbeitsverzeichnis verwenden

Mir ist aufgefallen, dass dies für einen neuen Go-Benutzer, der GOPATH nicht eingestellt hat, am nützlichsten sein könnte. Ein go get einem wget usw. und füllt das aktuelle Verzeichnis. Sie werden an dieser Stelle nicht im Weg Aspekte GOPATH interessieren, und ganz wollen möglicherweise ihr jedes Risiko in mit verschiedenen Online - Sachen spielen um verschieden zu sein, als ein neues temporäres Verzeichnis ihrer eigenen machen würden ihnen geben. Sie können die verschiedenen Repositorys abrufen, ausführen und einfach löschen, auf die sie verweisen.

• wenn GOPATH nicht gesetzt ist:
  
  
  
  • wenn nur ein oder zwei, aber nicht alle von ~/{bin,pkg,src} existieren:
  
  
  • sie müssen GOPATH setzen, pkg ist das ungewöhnliche
  
  
  • sonst sind entweder alle oder keine vorhanden:
  
  
  • Stellen Sie sicher, dass sie alle existieren
  
  
  • GOPATH=$(pwd)
  
  

Ich habe diesbezüglich gemischte Gefühle, aber meine vorherrschende Meinung (als jemand, der $GOPATH ) ist, dass go get Verhalten "deterministisch" sein sollte und immer Dinge unter $GOPATH installieren sollte – ein konsistentes und gut dokumentiertes Ziel.

Obwohl ich von dieser Änderung nicht betroffen bin, fühlt es sich seltsam an, dass go get Dinge an verschiedene Orte herunterlädt, je nachdem, was das Arbeitsverzeichnis ist, wenn der Befehl ausgegeben wird. Mir ist bewusst, dass dies wget , npm install und andere Tools tun, aber es fühlt sich an wie eine Abkehr von der Idee eines konsistenten $GOPATH Werts (so habe ich interpretierte den Geist dieser Änderung).

Wenn dies den Rahmen dieses Problems sprengt, würde ich vorschlagen, einfach zu beenden und einen Fehler auszugeben, wenn $HOME tatsächlich nicht festgelegt ist.

Ich habe 5 neue Programmierer unterrichtet, die aus der Java-Welt in einem Land der 3. Welt kamen .. Sie alle waren sicherlich verwirrt über GOPATH. Verdammt, ich war es auch, als ich wieder anfing, bevor Go 1 veröffentlicht wurde. Ich persönlich benutze "$HOME/gopath", aber ich schlage vor, dass der Befehl "go get" sie auf einen Go-Blog verweist, der KLAR ist, wie man einen Go-Pfad für ihr Betriebssystem erstellt. Das ist alles, was wir brauchen. Eine Anleitung durch den "go get"-Befehl, der keine Spezifikation ist.. Aber ein verdammt einfacher Blog-Post!!

Offensichtlich meine ich, wenn kein GOPATH gesetzt wurde. Aktualisieren Sie einfach die Fehlermeldung, die derzeit angezeigt wird. Die Akzeptanzrate ist bereits da. Ich brauche nur ein bisschen Hilfe anstelle der aktuellen Google-Methode, die Neulinge machen.

@einthusan Ich habe das Gefühl, dass es auf https://golang.org/doc/code.html#GOPATH ziemlich gut dokumentiert ist, aber ich weiß nicht, wie viele Leute, die mit Go angefangen haben, diese Seite tatsächlich lesen.

Tut mir leid für den Spam.. Nachdem ich etwas gegoogelt habe.. Ich denke, "go get" sollte den Benutzer nur dazu auffordern, zu sagen: "Es wurde kein GOPATH festgelegt... Möchten Sie das aktuelle Arbeitsverzeichnis als temporären GOPATH verwenden?" (Ja Nein)

@einthusan , es gibt keinen Präzedenzfall für cmd/go, das interaktive

Wenn der neue Standard-GOPATH $HOME/go ist. Würden die Leute nicht erwarten, dass dieses https://hub.docker.com/_/golang/ das gleiche Verhalten annimmt?

@cescoferraro das ist eine Frage an die Betreuer dieses Images. Obwohl es als "offiziell" gekennzeichnet ist, ist dieses Projekt nicht mit Go verbunden.

Beantworten/beantworten meiner eigenen Frage zu unset $HOME :

In der aktuellen Implementierung (die CL ist oben verlinkt) ist $GOPATH standardmäßig "" wenn $HOME ist: https://go-review.googlesource.com/#/ c/32019/11/src/go/build/build.go Ich denke, dies steht im Einklang mit dem aktuellen Verhalten.

Ich halte diesen Randfall für sehr unwahrscheinlich, da $HOME immer in einer normalen Login-Sitzung gesetzt wird, was wahrscheinlich für die meisten Go-Programmierer der Fall ist. Obwohl ich persönlich _mögen_, dass das Verhalten explizit geklärt wird, scheint es keine "Nebenwirkungen" zu geben (wie das Installieren von Dingen in Arbeitsverzeichnis). Korrigiere mich, wenn ich falsch liege. :)

Wenn dies den Leuten, die zum ersten Mal mit Go beginnen, einfacher machen soll, lass es so etwas wie den aktuellen Weg sein:

GOPATH=$(pwd)

Die Einstellung von export GOPATH=$(pwd) erleichtert das Umschalten zwischen Projekten

Mein vorgeschlagenes Verhalten für diese Änderung:

Umgebungsvariablen

• Wenn GOPATH ist, verhält sich das Werkzeug wie immer
• Andernfalls überprüfen wir die Umgebungsvariable HOME ( home für plan9, USERPROFILE für Windows).
  
  
  
  • Wenn diese env-Variable nicht gesetzt ist, wird auch GOPATH nicht gesetzt: Dies bedeutet, dass "go get" mit cannot download, $GOPATH not set. fehlschlägt
  
  

> unset GOPATH
> unset HOME
> go env GOPATH

• Andernfalls wird GOPATH als $HOME/go ( $home/go , %USERPROFILE%\go ) festgelegt.

> unset GOPATH
> go env GOPATH
/Users/campoy/go

GOPATH-Erstellung

Wenn $GOPATH derzeit nicht existiert, wird es erstellt, wenn wir go get import/path ausführen. Dies wird sich nicht ändern.

Die einzige Änderung besteht darin, dass, wenn $GOPATH nicht in der Benutzerumgebung festgelegt ist (dh echo $GOPATH zeigt keinen Wert an), eine zusätzliche Überprüfung durchgeführt wird, um sicherzustellen, dass der Standardwert akzeptabel ist:

• wenn GOPATH nicht gesetzt ist und kein Standardwert erstellt wurde: Der Befehl schlägt fehl

> unset GOPATH
> unset HOME
> go get github.com/golang/example/hello
package github.com/golang/example/hello: cannot download, $GOPATH not set. For more details see: 'go help gopath'
👎

• Wenn der Standardwert $GOPATH nicht existiert, wird eine Warnung angezeigt, die erklärt, dass das Verzeichnis erstellt wurde, und zeigt auf go help gopath für weitere Informationen.

> unset GOPATH
> go get github.com/golang/example/hello
warning: GOPATH is not set, creating directory /Users/campoy/go. See 'go help gopath' for more information
👍

• wenn der Standardwert $GOPATH existiert:
  
  
  
  • und es ist kein Verzeichnis: Der Befehl schlägt fehl (wie zuvor)
  
  

> unset GOPATH
> touch ~/go
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not a directory
👎

• und es ist entweder ein leeres Verzeichnis oder ein Verzeichnis mit einem Unterverzeichnis namens src der Befehl wird erfolgreich ausgeführt (keine Warnungen)

> unset GOPATH
> mkdir ~/go
> go get github.com/golang/example/hello
👍

> unset GOPATH
> mkdir -p ~/go/src
> touch ~/go/others
> go get github.com/golang/example/hello
👍

• und es ist ein nicht leeres Verzeichnis ohne ein Unterverzeichnis namens src der Befehl schlägt fehl

> unset GOPATH
> mkdir ~/go
> touch ~/go/others
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not empty, and no 'src' was found
👎

Daher wird nur eine neue Warnung eingefügt, wenn ein Verzeichnis mit einem Standardwert GOPATH .

@campoy der Verhaltensvorschlag sieht toll aus.

Aber als fortgeschrittener Benutzer möchte ich noch einmal wissen, wie viele von uns täglich ernsthaft $HOME/go als GOPATH ? Ich dachte sogar, vielleicht sollte es einen go-Befehl geben, um die GOPATH festzulegen, ähnlich wie beim Starten einer virtuellen Umgebung in einem Python-Arbeitsverzeichnis.

Da ich an mehreren Projekten arbeite, mache ich normalerweise so etwas:

$ cd foo-app
$ export GOPATH=$(pwd)

# switching to another app
$ cd ../foobar-app
$ export GOPATH=$(pwd)

@jinmatt
Diese Änderung ändert nur das Verhalten für nicht gesetztes GOPATH, das ist der Umfang der Änderung.
Die Community hat sich bereits auf $HOME/go geeinigt.

Wenn Sie $HOME/go nicht mögen, setzen Sie einfach GOPATH auf den Wert, den Sie bevorzugen (zB $HOME in meinem Fall).

Danke für die Designskizze.

1. Da wir jetzt festgestellt haben, dass GOPATH nur während 'go get' erstellt wird, lassen Sie uns Nachrichten nur dann ausgeben, wenn das Flag -v angegeben ist, im Einklang mit dem restlichen Verhalten von 'go get -v'.
2. Wenn das Verzeichnis erstellt ist, sollte die Nachricht höchstens lauten

# erstellt GOPATH=/users/campoy/go; siehe 'geh gopath helfen'

Es ist keine Warnung: Warnungen sind schlecht. Auf der anderen Seite, wenn das Erstellen fehlschlägt, möchten Sie vielleicht drucken

go: creating GOPATH=/users/campoy/go: %v

Diese beiden Nachrichten können unabhängig davon gedruckt werden, ob GOPATH abgeleitet oder explizit festgelegt wurde.

1. Die Heuristiken über leere Verzeichnisse und ein src-Unterverzeichnis sind zu komplex. Schlimmer noch, sie adressieren hypothetische Probleme, und hypothetische sind sehr schwer zu entwerfen. Besser ein einfacheres, vorhersehbareres Verhalten. Für den Anfang halte ich es für sinnvoll, keine Regeln zu haben, bis es konkrete Beispiele für tatsächliche Probleme gibt. Es wird Zeit für die Leute geben, Probleme während der Betas und Release-Kandidaten zu melden. Lassen Sie uns einfach GOPATH=$HOME/go setzen (vorausgesetzt, $HOME ist gesetzt).

Bearbeiten: Stellen Sie sich vor, dass der Github-Markdown das nicht vollständig vermasselt hat.

@campoy Was ist das aktuelle Verhalten von go get bezüglich des src/ Verzeichnisses, wenn ein GOPATH gesetzt ist, aber kein src-Verzeichnis existiert? Gibt es einen guten Grund, es nicht auch zu erstellen?

Es scheint nur einfacher zu erklären, ob $HOME/go/src beim ersten Aufruf erstellt wird (oder $GOPATH/src, wenn diese Umgebungsvariable gesetzt ist).

Heute, wenn GOPATH gesetzt ist, werden die notwendigen Verzeichnisse bedingungslos nach Bedarf erstellt.

CL https://golang.org/cl/33356 erwähnt dieses Problem.

CL https://golang.org/cl/33730 erwähnt dieses Problem.