Go: cmd/go : supposer GOPATH=$HOME/go si non défini

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

J'aime ça, mais avons-nous une préférence particulière pour "gocode" et pas quelque chose comme "gopath" ?

Combien de personnes utilisent déjà GOPATH=$HOME/gocode ? Il me semble pas beaucoup. Cela suggère que c'est la mauvaise valeur par défaut.

"gocode" aura un moteur de recherche et d'autres confusions avec l'outil populaire github.com/nsf/gocode.

Avons-nous des informations sur ce que font la plupart des gens ?

J'utilise moi-même GOPATH=$HOME/gopath.

Bravo ici si vous utilisez actuellement GOPATH=$HOME

Bravo ici si vous utilisez actuellement GOPATH=$HOME/gopath

Bravo ici si vous utilisez actuellement GOPATH=$HOME/gocode

Dois-je faire un sondage twitter sur @golang ?

@campoy ,

Que diriez-vous de $HOME/go (c'est ce que j'utilise).

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

$MAISON : 8,9 %
$MAISON/aller : 50,6 %
Autre : 40,5%

J'aurais vraiment aimé avoir divisé plus d'options pour celui-ci.

Le vote a commencé : https://twitter.com/golang/status/781189567437164544

Le mer. 28 sept. 2016, 10 h 51 Edward Muller [email protected]
a écrit:

Que diriez-vous de $HOME/go (c'est ce que j'utilise).

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -250244110, ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

Voir aussi la colonne I ici : https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid =1525640201

@freeformz ,

$HOME/go est en conflit avec le chemin d'accès, le code source (go.googlesource.com/go) est souvent extrait. Il est dommage que la communauté ait béni cet emplacement par défaut pour GOPATH :( Je m'inquiète si quelqu'un oublie de définir son GOPATH et exécute l'outil go, cela perturbera son répertoire de développement actuel.

@rakyll à chacun le sien, je voulais juste indiquer ce que moi et beaucoup d'autres utilisons. go.googlesource.com/go est extrait dans /usr/local/go.git sur mon système.

Combien de personnes utilisent déjà GOPATH=$HOME/gocode ? Il me semble pas beaucoup. Cela suggère que c'est la mauvaise valeur par défaut.

Pour mémoire, j'utilise GOPATH=$HOME , mais j'ai pensé que ce serait trop litigieux et nuirait à l'objectif de cette proposition qui est d'améliorer l'expérience pour le nouvel utilisateur.

@freeformz , je suppose que nous n'avons pas à nous soucier des chemins canoniques existants qui sont en dehors de $HOME. La valeur par défaut de GOPATH sera quelque part dans $HOME et l'exigence minimale devrait être qu'elle n'entre en conflit avec aucun chemin critique existant.

$HOME/gocode me semble étranger mais cela pourrait être un très bon choix.

Le fait est que peu importe la valeur par défaut, juste qu'il y en ait une.

La valeur par défaut est importante, car la définition de cette valeur par défaut permettra essentiellement à tous les nouveaux utilisateurs de Go de fonctionner dans quelques années.

La commande go fait tout son possible pour ne pas se tromper lorsque GOPATH=$GOROOT explicitement ; Je suis sûr que la même logique peut être appliquée à un paramètre implicite également. Je ne suis donc pas trop inquiet de briser accidentellement $HOME/go.

Je me demande toujours si, au lieu d'une valeur par défaut fixe, nous devrions renifler automatiquement les parents du répertoire actuel pour déterminer où se trouve GOPATH. C'est ce que font de nombreux outils source de nos jours (par exemple, chaque système de contrôle de version), c'est donc un concept que les gens comprendraient. Et cela ne les oblige pas à utiliser un seul nom de répertoire ou à n'avoir qu'un seul espace de travail GOPATH. Mais nous pourrions aussi bien avoir cette discussion sur la question initiale.

@rsc J'aimerais que la valeur par défaut soit GOPATH=$HOME car cela signifie que $GOPATH/bin sera sur leur chemin (au moins sur la plupart des distributions Linux, je ne suis pas sûr de darwin).

$GOPATH=$HOME/go est également un bon choix et ceux qui ont vérifié la source du compilateur auront déjà défini GOPATH=something else donc il n'y a aucun risque de conflit.

Pour être clair, je n'essayais pas d'être désinvolte quand j'ai dit

Le fait est que peu importe la valeur par défaut, juste qu'il y en ait une.

Essayer plutôt de souligner le but de cette proposition est de faire en sorte que l'outil go utilise une valeur par défaut pour $GOPATH lorsqu'il n'y en a pas car c'est une source continue de confusion et de frustration pour tant de nouveaux arrivants dans la langue.

Je suis sur le reniflement automatique car il échoue à un cas d'utilisation majeur, à savoir :

1. J'ai installé Go, je n'ai pas lu la documentation d'installation de Go, j'ai juste suivi ce qu'il disait sur le README du dépôt qui disait brew install go
2. J'ai couru go get github.com/thething/theproject
3. Maintenant, j'obtiens une erreur sur le fait de ne pas définir $GOPATH. Qu'est-ce que c'est? Je voulais juste lancer ce programme sur lequel quelqu'un a tweeté !

Une valeur par défaut de GOPATH=$HOME/go SGTM, en supposant que nous décidions d'une approche par défaut et non d'un reniflage automatique.

La commande go fait tout son possible pour ne pas se tromper lorsque GOPATH=$GOROOT explicitement ; Je suis sûr que la même logique peut être appliquée à un paramètre implicite également.

Super.

pas sûr pour darwin

Pas sur Darwin.

Si c'est pour les nouveaux arrivants, je déconseillerais GOPATH=$HOME car cela créerait trois répertoires dans leur répertoire personnel au lieu d'un seul. Je n'aime pas les logiciels qui polluent mon répertoire personnel au-delà de ce qui est nécessaire.

@mvdan Je comprends et votre réaction était pourquoi je n'ai pas proposé GOPATH=$HOME .

Si _Je_ souhaite personnellement définir mon GOPATH sur $HOME , alors cette option resterait disponible et je n'aurais à apporter aucune modification si cette proposition était acceptée pour Go 1.8.

@davecheney

par défaut à une valeur de GOPATH=$HOME/gocode

Il n'y a pas de variable HOME par défaut sous Windows. Que proposez-vous de faire sous Windows ?

J'aimerais que la valeur par défaut soit GOPATH=$HOME car cela signifie que $GOPATH/bin sera sur leur chemin

Je suis toujours inquiet d'avoir $GOPATH/bin dans mon PATH. go get installe les programmes d'autres personnes. Voulons-nous vraiment que les nouveaux utilisateurs de Go installent des programmes aléatoires à partir d'Internet quelque part dans leur PATH ?

Alexis

Je ne suis pas un utilisateur Windows expérimenté, mais je suppose qu'il existe une notion de chemin de base où les documents et les paramètres sont stockés. Aux fins de cette discussion, supposons que je parle de ce chemin dans le contexte des utilisateurs Windows.

Si un tel chemin n'existe pas, supposez C:/gocode.

En ce qui concerne mon commentaire sur GOPATH=$HOME, bien que ce soit et continuera d'être ma préférence personnelle, je reconnais qu'il s'agit d'une option controversée pour une valeur par défaut et en tant que telle, je ne l'ai pas suggérée comme valeur proposée.

L'auto-détection est pleine de dangers. J'ai commencé à le prototyper il y a quelque temps, mais cela a ajouté une complexité significative à la fois à l'outil de démarrage et à l'expérience utilisateur.

Je ne suis pas au courant de ce qui se passe avec le groupe de travail sur la gestion des packages, mais je peux imaginer un avenir pas si lointain où GOPATH serait complètement éliminé.

Cela dit, même si GOPATH disparaît dans un avenir proche, il peut toujours être utile de définir une valeur par défaut. Si nous pensons que GOPATH est susceptible de disparaître, peu importe ce que nous l'avons défini.

D'après ce que j'ai lu ci-dessus, il y a un certain consensus que :

1. Par défaut, GOPATH=$HOME est trop invasif.
2. La valeur par défaut devrait inclure la chaîne go quelque part (probablement comme préfixe).

Je ne crains pas que GOPATH soit un clone du dépôt principal de go (c'est-à-dire GOPATH == GOROOT). Les personnes qui consultent le dépôt go sont susceptibles d'avoir un ensemble GOPATH. L'outil go détecterait le conflit de toute façon, comme il le fait aujourd'hui.

Dans cet esprit, la valeur par défaut la plus succincte serait $HOME/go , ce qui me semble tout à fait raisonnable.

Je suppose qu'il existe une notion de chemin de base où les documents et les paramètres sont stockés.

Je ne connais pas une telle chose. Peut-être que d'autres utilisateurs de Windows commenteront ici.

Si un tel chemin n'existe pas, supposez C:/gocode.

Vous voulez plutôt C:gocode.
Mettre des choses à la racine de C:\ ne me semble pas correct. Recommanderiez-vous que GOPATH soit défini sur /gocode sous Linux ?
Mais, étant donné que le programme d'installation de Windows installe déjà Go dans C:go, C:gocode pour GOPATH est au moins cohérent.

Alexis

Mais, étant donné que le programme d'installation de Windows installe déjà Go dans C:go, C:gocode pour GOPATH est au moins cohérent.

GOPATH ne doit pas être fourni pour chaque utilisateur ? Pour être le même qu'UNIX, %USERPROFILE%\gocode , je suppose.

Sondage Go+ sur https://goo.gl/xAsgEj

après avoir utilisé pendant longtemps quelque chose comme $HOME/go-programs, j'ai basculé GOPATH sur $HOME. donc maintenant j'ai la structure suivante:

$ACCUEIL/bac
$MAISON/pqt
$ACCUEIL/src/
$HOME/src/github.com/user/some_github_project
$HOME/src/un_projet

cette structure est plus générique et peut également être utilisée avec d'autres langages ou projets et avec github. par exemple, j'ai $HOME/src/talks (lisez-le home/sources/talks pour les fichiers de démarques) ou d'autres projets dans certaines langues (comme $HOME/src/github.com/user/html) mais aussi des sources et j'en ai un place pour de nombreuses sources de projets avec ou sans correspondance github.

bin ou pkg peut être considéré comme désordonné mais je pense que ce n'est pas si ennuyeux. est plus compliqué d'avoir de nombreux dossiers source pour les personnes qui utilisent plusieurs langues.

donc, de mon point de vue, le meilleur endroit GOPATH est $HOME.

J'utilise $HOME/gocode comme GOPATH.
Je suis contre $HOME/go car parfois vous n'avez pas le privilège root et vous devez installer Go dans votre répertoire personnel. Dans ce cas, je pense que $HOME/go serait le meilleur pour GOROOT.
Nous devrions donc utiliser quelque chose de différent de $HOME/go comme GOPATH.

@hnakamur À l'époque où j'ai installé Go manuellement (maintenant en utilisant Ubuntu Make), je l'ai mis dans $HOME/bin/go-${go_version} (avec un lien symbolique de $HOME/bin/go vers $HOME/bin/go-$ {version}/bin/go, donc je n'ai pas eu à modifier mon $PATH)

@tbroyer C'est du créneau. Je suppose que la plupart des utilisateurs ne veulent pas de configuration ou de paramètres supplémentaires. À mon avis, ~/bin est déjà utilisé pour mettre son propre script ou ses binaires (comme moi). Et je pense que ~/bin (~/src, ~/pkg) rend difficile la suppression des binaires go.

J'utilise $HOME pour mon GOPATH.
Pourquoi définir automatiquement GOPATH, pourquoi ne pas déclencher un avertissement avec de bonnes informations sur la façon de le définir si GOPATH n'existe pas ?

Pourquoi définir automatiquement GOPATH, pourquoi ne pas déclencher un avertissement avec de bonnes informations sur la façon de le définir si GOPATH n'existe pas ?

Le problème n'est pas que les gens ne savent pas comment définir une variable d'environnement (pour la plupart), c'est que même si vous le faites, il est difficile de devoir sauter à travers les cerceaux pour commencer à utiliser Go. Être capable d'utiliser Go out of the box avec des valeurs par défaut saines dès qu'il est installé rend l'expérience aussi transparente que possible, et signifie que plus de gens sont susceptibles d'essayer réellement Go après l'avoir téléchargé, au lieu de heurter un barrage routier, de perdre leur élan, et décider que cela ne vaut pas la peine de jouer avec.

J'ai tendance à être d'accord avec Chris et Andrew : s'il doit y avoir un GOPATH par défaut, il devrait être juste $HOME/go, pas gopath ou gocode. _La plupart_ des utilisateurs n'ont pas de distribution Go vérifiée là-bas (et tous ceux qui le font aujourd'hui définissent déjà GOPATH, donc cela ne les dérangera pas). La valeur par défaut doit avoir un sens pour les nouveaux utilisateurs, pas pour les utilisateurs avancés, et pour la plupart des utilisateurs, $HOME/go a beaucoup de sens.

Jaana s'est inquiétée de la confusion de la commande go si $HOME/go se trouve être une distribution Go, mais la commande go vérifie déjà la présence accidentelle de GOPATH=$GOROOT. Il est facile de vérifier si cela est vrai lorsque GOPATH est également défini implicitement. En fait, il serait également facile d'augmenter la vérification pour rechercher, par exemple, $HOME/go/src/cmd/go/alldocs.go, pour éviter toute confusion même lorsque GOROOT!=$HOME/go mais $HOME/go le fait contiennent une distribution Go.

$HOME/go n'est pas une bonne option pour GOPATH. faisons un simple exercice de comportement... les nouveaux utilisateurs peuvent facilement considérer la valeur par défaut comme une bonne pratique. disons que je suis un nouvel utilisateur, pourquoi devrais-je considérer les valeurs par défaut comme une mauvaise chose ? plus que cela, la méthode la plus simple (et la meilleure?) Pour installer golang est de décompresser dans $HOME car avec cette méthode, le compilateur est toujours à la dernière version et n'a pas besoin de droits root, vous pouvez donc facilement supposer que de nombreux utilisateurs auront go compilateur dans $HOME/go. pourquoi devrais-je déplacer le compilateur dans /usr/local alors que je ne l'ai tout simplement pas fait ?
plus que cela, ils peuvent créer des projets et cloner des projets dans ce dossier. ainsi, ils auront un dossier en désordre et avec un peu d'imprudence, ils pourront facilement supprimer leur dossier de projet avec une nouvelle réinstallation de golang.
De plus, les utilisateurs de Windows ont c:go par défaut.

J'aime $HOME/gopath. Il dit ce que c'est.
Le premier résultat sur Google pour "gopath" est la bonne page.

Si une valeur par défaut est adoptée, une fonction func GOPATH() string pourrait-elle être ajoutée à runtime ? À l'heure actuelle, on peut utiliser os.Getenv() , mais avec une valeur par défaut, ce ne sera pas si simple.

@btracey , GOPATH est une liste, pas une valeur unique. Utilisez filepath.SplitList . De plus, GOPATH n'est pas une fonction du runtime. Cela ne concerne que cmd/go .

Pour une compatibilité descendante, nous aurions probablement besoin de définir GOPATH dans le processus'
environnement si aucun n'est défini.

Le 30 septembre 2016 à 08h10, Brendan Tracey [email protected]
a écrit:

Si une valeur par défaut est adoptée, une fonction de chaîne func GOPATH() pourrait-elle être ajoutée
à l'exécution ? À l'heure actuelle, on peut utiliser os.Getenv(), mais avec une valeur par défaut, il
ne sera pas si simple.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -250605418, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

Tu as raison @bradfitz. La solution proposée par @adg répondrait à tous mes usages.

C'est une ride intéressante. Je peux voir cela échouer actuellement quand non
GOPATH est défini, mais aussi lorsque GOPATH contient plusieurs valeurs, puis
il existe des cas où l'application est construite sur une machine et déployée sur
un autre.

Je ne veux pas rejeter cette utilisation de GOPATH, je comprends la douleur de
être en mesure de localiser les fichiers de support pour votre application, mais j'aimerais
comprendre à quel point cet usage est répandu et comment le
les implémentations traitent des problèmes que j'ai soulignés ci-dessus.

Le vendredi 30 septembre 2016, 08:35 Brendan Tracey [email protected] a écrit :

Vous avez raison @bradfitz https://github.com/bradfitz. La solution
proposé par @adg https://github.com/adg répondrait à tous mes usages.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -250611813, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

Mon utilisation n'est pas normale. Je fais des recherches scientifiques, et j'ai trouvé très efficace non seulement d'avoir gopath/src et gopath/bin , mais aussi gopath/data et gopath/results . Cela facilite la copie des fichiers source sur un nouveau système sans avoir à copier également les (gigaoctets de) fichiers de résultats. Le nouveau système (disons un cluster) génère de nouveaux fichiers de résultats, et je peux copier ces résultats dans un emplacement central. Il est très facile de dire ensuite gopath = os.Getenv("GOPATH") , et d'enregistrer un fichier dans quelque chose comme filepath.Join(gopath, "results", "projectname", result.json) .

Merci. Pour être clair, je ne voulais pas dire que votre utilisation était incorrecte ou
faux, je voulais juste comprendre cette utilisation de GOPATH par rapport au
contraintes que j'ai soulignées.

Le vendredi 30 septembre 2016, 09:09 Brendan Tracey [email protected] a écrit :

Mon utilisation n'est pas normale. Je fais de la recherche scientifique et j'ai trouvé
il est très efficace d'avoir non seulement gopath/src et gopath/bin, mais aussi
gopath/data et gopath/results. Cela facilite la copie de la source
fichiers sur un nouveau système sans avoir à copier les (gigaoctets de)
fichiers de résultats. Le nouveau système (disons un cluster) génère de nouveaux fichiers de résultats,
et je peux copier ces résultats dans un emplacement central. C'est vraiment facile de
puis dites gopath = os.Getenv("GOPATH"), et enregistrez un fichier dans quelque chose comme filepath.Join(gopath,
"résultats", "nom du projet", result.json).

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment-250617618 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

Bravo si vous utilisez actuellement GOPATH=$HOME/.go

@davecheney aucune offense, je voulais juste fournir suffisamment de contexte pour être utile.

Laissons s'il vous plaît l'utilisation de GOPATH pour trouver des fichiers de support hors de cette discussion.

(GOPATH est censé être un paramètre de compilation, pas un paramètre d'exécution. Je sais que les gens les brouillent parfois et utilisent GOPATH pour trouver les fichiers associés au moment de l'exécution, mais je ne pense pas que nous devrions encourager cela ou faire c'est plus facile à faire. Nous avons besoin d'une meilleure histoire pour les fichiers de support en général, mais cela devrait être un problème distinct.)

Lié à la recherche de fichiers associés au moment de l'exécution : #12773

Désolé de polluer la discussion une fois de plus @rsc , mais @randall77 , #12773 est plus difficile à utiliser que de simplement contourner ce problème directement. Le code spécifique qui a besoin d'un fichier (ou pour enregistrer un fichier) peut se déplacer beaucoup, et je veux un endroit fixe pour les entrées/sorties à vivre indépendamment (et séparé de) la refactorisation.

Ce problème concerne une valeur par défaut possible de GOPATH. Il ne s'agit _pas_ d'utilisations alternatives de GOPATH.

Si les utilisateurs cibles de ce changement sont uniquement ceux qui voulaient simplement
installer un nouveau programme écrit en Go, et non ceux qui veulent réellement
écrivez Go, alors qu'en est-il de faire aller cloner dans un répertoire par utilisateur dans
$TMPDIR, et laisser le binaire à $PWD si $GOPATH n'est pas défini ? (Évidemment
cela n'a de sens que pour aller chercher import.path/for/a/command, s'il ne s'agit pas d'un
commande, go get devrait échouer sans que $GOPATH ne soit défini)

Pour l'étranger, cela a beaucoup de sens, tout comme wget un fichier.

Une fois que l'utilisateur veut commencer à écrire du code Go, il doit apprendre à définir
GOPATH correctement.

Je suis contre $HOME/go car parfois vous n'avez pas le privilège root et vous devez installer Go dans votre répertoire personnel. Dans ce cas, je pense que $HOME/go serait le meilleur pour GOROOT.

Si vous êtes sur un système Linux, je dirais que le meilleur endroit pour $GOROOT pourrait être dans $HOME/.local/opt/go, pas $HOME/go, selon la façon dont vous interprétez le but de $HOME/.local , car seul $HOME/.local/share (apparaissant en miroir /usr/local/share) est défini dans la spécification du répertoire de base XDG : https://standards.freedesktop.org/basedir-spec/basedir-spec-latest. html.

On pourrait également affirmer que la meilleure valeur par défaut pour GOPATH / GOBIN (sous Linux) devrait être :
GOPATH=$XDG_DATA_HOME/go, ou $HOME/.local/share/go
GOBIN=$HOME/.local/bin

Cependant, ce n'est probablement pas le plus facile à comprendre pour les nouveaux utilisateurs ? Et cela ne permettrait pas non plus de savoir quelle est la meilleure approche sous Windows. $HOME/go et $USERPROFILE/go semblent pragmatiques.

S'il vous plaît, _veuillez_ ne pas laisser ce fil se transformer en une discussion sur les noms de chemin Linux canoniques et les emplacements de stockage. Ce n'est pas productif, et je pense que cette discussion s'est déjà éloignée assez loin du message initial de Dave Cheney.

Je ne suis pas non plus sûr que l'emplacement absolu réel ait autant d'importance, je pense que tout ce que ce fil a vraiment besoin de décider est "voulons-nous un Gopath par défaut?" (on dirait que c'est un oui plus ou moins écrasant) et "devrait-il être partagé à l'échelle du système ou local pour l'utilisateur" (jusqu'à présent, la plupart des discussions ont porté sur le local). Après cela, quiconque implémente peut choisir $HOME/gocode ou $HOME/go ou /usr/share/go/ ou tout ce qu'il désire qui semble raisonnable à quiconque examine le PR, et les choses continueront probablement à se passer plutôt bien.

Je pense qu'un GOPATH à l'échelle du système est un non-démarreur en raison de problèmes d'autorisations.

​

Le chemin à l'échelle du système est, pour le meilleur ou pour le pire, GOROOT, qui distribue
comme debian l'utilisent pour installer des paquets "à l'échelle du système", pour le meilleur ou pour
pire.

Un GOPATH à l'échelle du système n'est pas couvert par cette proposition, cette proposition
recommande un chemin dérivé de la valeur de l'utilisateur connecté.

Le mardi 4 octobre 2016, 08:52 Andrew Gerrand [email protected] a écrit :

Je pense qu'un GOPATH à l'échelle du système est un non-démarreur en raison de problèmes d'autorisations.

​

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -251238251, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

S'il vous plaît, s'il vous plaît, ne laissons pas ce fil se transformer en une discussion sur les noms de chemin Linux canoniques et les emplacements de stockage. ce n'est pas productif

D'accord, non. Mon point principal était vraiment de souligner une autre raison pour laquelle $HOME/go n'est probablement pas problématique en tant que valeur par défaut de GOPATH, car ce n'est probablement pas le chemin le plus "idiomatique Linux" pour les installations des utilisateurs locaux de Go (aka GOROOT) de toute façon.

En dehors de cela, je pense qu'il a déjà été discuté d'utiliser XDG_CACHE_HOME pour un GOPATH par défaut, c'est pourquoi j'ai mentionné XDG_DATA_HOME -- bien que je ne sache pas quel rôle les auteurs du document lié jouent, ni à quel point il est "officiel" .

$MAISON/travail.......

@adg @quentinmit @rsc quelles sont les prochaines étapes pour cette proposition ?

J'adorerais vraiment voir quelque chose se passer ici. c'est un point douloureux fréquent dans mes cours. Tout défaut (même $home/go avec lequel je ne suis pas d'accord :) ) vaut mieux que rien.

$HOME/go ce sera. Il n'y a pas de meilleure réponse, mais c'est court et doux, et cela ne peut être un problème de choisir ce nom que si $HOME/go existe déjà, ce qui ne fera que ravir les experts qui ont déjà installé go et comprendront GOPATH.

Qui veut faire le travail ?

Je serais certainement heureux de travailler là-dessus.

@campoy , pouvez-vous le faire <= ce vendredi ?

Je dirais que oui @bradfitz . Cela ne ressemble pas à une énorme quantité de code à faire.
Je peux commencer demain.

mise à jour : j'ai jeté un rapide coup d'œil à cela et j'ai déjà écrit du code, j'ajouterai des tests et enverrai un changement plus tard dans la journée

C'est super les gars ! ??

@robpike avez-vous également envisagé ma proposition alternative dans #17271 ? Je voudrais comprendre pourquoi cette proposition a été jugée meilleure

Ce ne sera pas une bonne idée d'avoir les mêmes noms de répertoire d'installation Go et de répertoire de l'espace de travail, c'est- go dire

1) Il est très facile pour un utilisateur naïf de corrompre/polluer l'espace de travail si l'utilisateur fait tar -xzf go$VERSION.$OS-$ARCH.tar.gz dans le répertoire personnel

2) L'expérience par défaut d'un nouvel utilisateur lorsqu'il n'installe pas à /usr/local (ne veut pas installer en tant que root) ne sera pas fluide car ce sera le flux :
Télécharger go$VERSION.$OS-$ARCH.tar.gz
tar -xzf go$VERSION.$OS-$ARCH.tar.gz --> s'installe dans $HOME/go
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something --> jetés cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

@krishnasrinivas , je crois comprendre que si GOROOT=$HOME/go , cette valeur par défaut n'aura pas lieu ou fera go erreur GOROOT et GOPATH ne peuvent pas être identiques. Dans de tels cas, comme indiqué précédemment, on s'attend à ce que l'utilisateur soit suffisamment capable de définir son propre GOPATH .

@mvdan correct, pour les nouveaux utilisateurs qui ne souhaitent pas utiliser les privilèges root pour l'installation (et donc de fortes chances d'installer Go in ~/go), nous ne facilitons pas la mise en route car ils devront explicitement définissez GOPATH sur autre chose. Cela peut être facilement corrigé si GOPATH par défaut est ~/gopath ou ~/gocode

Pour l'installation non root, si de nouveaux utilisateurs doivent profiter de GOPATH=~/go par défaut, la documentation d'installation doit être légèrement plus compliquée en demandant explicitement aux utilisateurs d'utiliser l'option tar -C afin de ne pas l'installer à ~/go

@rasky Je considère #17271 et cette proposition comme orthogonale. La résolution de cette proposition est une victoire facile qui ne nous pousse pas dans une direction particulière. Je développerai davantage cette question.

Je suis d'accord avec @krishnasrinivas. Je n'avais pas d'autorisations root, alors j'ai juste détaré Go to $HOME/go. J'ai également défini mon $GOPATH=$HOME/gowork.

@krishnasrinivas @joegrasse Il n'y a pas de solution parfaite. Il est facile de définir vous-même GOPATH , et je pense que c'est ce que la plupart des gens feront. La question ici est de savoir ce que nous devons faire pour les personnes les plus récentes à Go. Ce ne sont pas en général des personnes qui installent leur propre distribution Go dans des emplacements personnalisés. Les personnes qui peuvent comprendre comment installer Go dans un emplacement personnalisé peuvent comprendre comment définir GOPATH .

Pensez plutôt à une classe de nouveaux programmeurs qui utilisent des distributions Go préinstallées. Nous voulons qu'ils puissent commencer à écrire du code Go. Nous ne voulons pas que la première étape soit "voici ce qu'est une variable d'environnement. Voici comment vous en définissez une. Maintenant, définissez GOPATH sur ceci." Ces étapes n'ont rien à voir avec le Go en tant que tel.

Encore une fois, il n'y a pas de solution parfaite, mais il semble sage de choisir quelque chose.

@ianlancetaylor Je suis tout à fait d'accord pour dire que quelque chose devrait être choisi. Je pense simplement qu'avec go untaring to ./go, par défaut $HOME/go, ce n'est peut-être pas le meilleur choix.

@ianlancetaylor GOPATH=$HOME/gopath est une meilleure valeur par défaut que GOPATH=$HOME/go pour les raisons susmentionnées.

Je ne pense pas que le nom actuel soit un problème - si vous savez comment définir PATH pour un emplacement go/bin personnalisé sous votre répertoire d'origine, vous savez comment définir GOPATH.

@joegrasse @krishnasrinivas Jetez un œil à " Installation à un emplacement personnalisé ".

Si vous décompressez ailleurs que /usr/local/go -- pour des raisons d'autorisations ou autrement -- il devient nécessaire de définir GOROOT également, ou de compiler à partir des sources.

Tant que c'est le cas, il n'y a aucun avantage à utiliser $HOME/gopath, etc. par rapport au $HOME/go proposé.

Vous supposez que les nouveaux utilisateurs préfèrent installer à partir du tar.gz. je peux citer non
chiffres, mais croyez que votre réponse est basée sur les installations Linux, qui
sont la troisième cible d'installation la plus populaire pour go.

Le Mar 25 Oct 2016, 20:28 Krishna Srinivas [email protected]
a écrit:

@mvdan https://github.com/mvdan correct, pour les utilisateurs qui ne veulent pas
utiliser les privilèges root pour l'installation (et donc de fortes chances d'installer
Allez ~/go) nous ne facilitons pas la mise en route des choses car
ils devront explicitement définir GOPATH sur autre chose. Cela peut être
facilement corrigé si GOPATH est soit ~/gopath soit ~/gocode

Pour l'installation non root, si de nouveaux utilisateurs doivent profiter de la valeur par défaut
GOPATH=~/go alors la documentation doit être un peu plus compliquée
en demandant explicitement aux utilisateurs d'utiliser l'option tar -C afin de ne pas l'installer à
~/aller

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -255984498, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

Les docs doivent tous être mis à jour aussi. C'est probablement le gros du travail.

Le 25 octobre 2016 à 10h14, Francesc Campoy [email protected]
a écrit:

Je dirais que oui. Cela ne ressemble pas à une énorme quantité de code à faire.
Je peux commencer demain.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -255892314, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

Je dirais que oui. Cela ne ressemble pas à une énorme quantité de code à faire.
Je peux commencer demain.

Le lundi 24 octobre 2016 à 16h05 Brad Fitzpatrick [email protected]
a écrit:

@campoy https://github.com/campoy , pouvez-vous le faire avant <= ce vendredi ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -255890668, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

Je peux aider avec les docs si nécessaire. Le seul problème est que le matériel actuel dépend uniquement de GOPATH comme point de référence. Par exemple,

"Ou, comme vous avez ajouté $GOPATH/bin à votre PATH , tapez simplement le nom binaire :"

ou

"Créer un package sous GOPATH, mkdir -p $GOPATH/src/github.com/user/hello"

Sans s'engager avec GOPATH et apprendre ce que c'est, il est presque impossible de faire quoi que ce soit dans Go autre que d'obtenir des packages tiers. Si nous pouvons signaler le chemin par défaut via go env , ce serait facile de s'y référer dans la documentation.

Peut-être que $HOME/go/... pourrait être remplacé à la place (ou l'équivalent sous Windows) ?

Comme vous avez ajouté $HOME/go/bin à votre PATH (ou $GOPATH/bin si GOPATH est défini)...

Peut-être qu'à un moment donné, la documentation pourrait s'attendre à ce que les individus définissent non seulement la variable d'environnement PATH, mais également GOPATH sur $HOME/go. Même s'il est redondant, il prépare l'utilisateur à des références ultérieures à GOPATH.

La documentation initiale pourrait supposer la valeur par défaut et ne pas mentionner du tout les variables d'environnement.

Vous supposez que les nouveaux utilisateurs préfèrent installer à partir du tar.gz. je peux citer non
chiffres, mais croyez que votre réponse est basée sur les installations Linux, qui
sont la troisième cible d'installation la plus populaire pour go.

Vous avez raison, mon avis est biaisé en faveur des installations Linux. Je peux voir que pour les nouveaux utilisateurs qui installent go dans /usr/local, ~/go pourrait être un nom de répertoire plus reconnaissable que ~/gopath

La documentation initiale pourrait supposer la valeur par défaut et ne pas mentionner
variables d'environnement du tout ?

Oui, j'espère que tout le débat distrayant sur la configuration de GOPATH peut être déplacé
à une annexe de la documentation d'installation, comme nous le faisons pour GOROOT
actuellement.

Le mercredi 26 octobre 2016, 06:01 Nathan Youngman [email protected] a écrit :

Peut-être que $HOME/go/... pourrait être remplacé à la place (ou l'équivalent sur
Les fenêtres)?

Comme vous avez ajouté $HOME/go/bin à votre PATH (ou $GOPATH/bin si GOPATH est
ensemble)...

Peut-être qu'à un moment donné, la documentation pourrait s'attendre à ce que les individus ne
définissez uniquement la variable d'environnement PATH, mais également GOPATH sur $HOME/go.
Même s'il est redondant, il rend la documentation ultérieure claire.

La documentation initiale pourrait supposer la valeur par défaut et ne pas mentionner l'environnement
variables du tout ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

La documentation initiale pourrait supposer la valeur par défaut et ne pas mentionner du tout les variables d'environnement.

SGTM

Il existe deux types d'utilisateurs Go :

• Les utilisateurs qui se contentent d'aller chercher des packages existants
• Utilisateurs qui sont des développeurs Go

GOPATH par défaut corrige le cas du premier groupe. Nous pouvons toujours conserver les instructions liées à GOPATH pour les documents destinés aux développeurs. L'installation ne devrait plus du tout mentionner la configuration de GOPATH ou nous pouvons avoir une annexe comme le mentionne @davecheney .

En tant que personne qui a dû renommer ~/bin/go à cause de Go, j'aime suggérer que, quelle que soit la valeur par défaut, s'il existe déjà, il doit contenir un fichier .dot pour indiquer qu'il s'agit vraiment du ~/go de Go. Lorsque ~/go n'existe pas, go peut le créer, créer le fichier .dot et les futures exécutions peuvent le trouver. Si je définis explicitement GOPATH sur ~/go, aucun fichier .dot ne sera nécessaire car aucune valeur par défaut n'est utilisée.

Le fichier de points existe. C'est le répertoire src/ dans $HOME/go.

Le mercredi 26 octobre 2016, 07:59 RalphCorderoy [email protected] a écrit :

En tant que personne qui a dû renommer ~/bin/go à cause de Go, j'aime suggérer
que quelle que soit la valeur par défaut, s'il existe déjà, il doit avoir un
.dotfile pour indiquer que c'est vraiment Go's ~/go. Quand ~/go n'existe pas,
go peut le créer, créer le fichier .dot et les futures exécutions peuvent le trouver. Si je
définissez explicitement GOPATH sur ~/go, aucun fichier .dot ne sera nécessaire car aucun
la valeur par défaut est utilisée.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -256173981, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

CL https://golang.org/cl/32019 mentionne ce problème.

Même si certains programmeurs ne connaissent pas les variables d'environnement, ils
devrait au moins être familier avec _variables_. Je pense que nous allons avoir besoin
utiliser quelque chose pour décrire l'emplacement d'un espace de travail dans les documents, et
la chaîne $GOPATH pourrait tout aussi bien l'être.

Le 26 octobre 2016 à 06h24, Jaana Burcu Dogan [email protected]
a écrit:

La documentation initiale pourrait supposer la valeur par défaut et ne pas mentionner l'environnement
variables du tout.

SGTM

Il existe deux types d'utilisateurs Go :

• Les utilisateurs qui se contentent d'aller chercher des packages existants
• Utilisateurs qui sont des développeurs Go

GOPATH par défaut corrige le cas du premier groupe. On peut encore garder
Instructions liées à GOPATH pour les documents destinés aux développeurs. Les
l'installation ne devrait plus du tout avoir à mentionner la configuration de GOPATH ou nous
peut avoir une annexe comme @davecheney https://github.com/davecheney
mentionne.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -256149104, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

Merci est l'intention, s'il vous plaît voir la proposition originale.

En effet on peut maintenant dire " go get va télécharger la source dans un dossier
appelé, allez/src/github.com/Foo/Bar dans votre répertoire personnel"

Le mercredi 26 octobre 2016, 06:01 Nathan Youngman [email protected] a écrit :

Peut-être que $HOME/go/... pourrait être remplacé à la place (ou l'équivalent sur
Les fenêtres)?

Comme vous avez ajouté $HOME/go/bin à votre PATH (ou $GOPATH/bin si GOPATH est
ensemble)...

Peut-être qu'à un moment donné, la documentation pourrait s'attendre à ce que les individus ne
définissez uniquement la variable d'environnement PATH, mais également GOPATH sur $HOME/go.
Même s'il est redondant, il rend la documentation ultérieure claire.

La documentation initiale pourrait supposer la valeur par défaut et ne pas mentionner l'environnement
variables du tout ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

Ce serait un grand problème pour la dernière semaine du Hacktoberfest

Le fichier de points existe. C'est le répertoire src/ dans $HOME/go

"src" est bien trop commun pour être un fichier de points "cela a été créé en tant que GOPATH par défaut par Go".

Quelle est la chose que vous essayez d'empêcher?

Le mercredi 26 octobre 2016 à 9h20, RalphCorderoy [email protected]
a écrit:

Le fichier de points existe. C'est le répertoire src/ dans $HOME/go

"src" est bien trop commun pour être un "cela a été créé comme GOPATH par défaut par
Allez" dotfile.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -256194536, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$HOME/go ce sera.

Qu'en sera-t-il pour les utilisateurs de Windows ?

Alexis

Les utilisateurs de Windows utiliseront %USERPROFILE%\go , comme Docker le fait ici .

@davecheney , j'essaye d'empêcher ce que j'ai dit il y a deux heures : https://github.com/golang/go/issues/17262#issuecomment -256173981

Aller est un mot commun. J'ai eu un ~/bin/go. Les gens jouent au go et ont du code source pour jouer au go. Attraper ~/go par défaut lorsqu'il existe déjà simplement parce qu'il contient src est impoli. Si ~/go n'existe pas, Go peut récupérer le nom, créer le répertoire, le marquer comme golang avec un fichier de points significatif, par exemple basé sur le nom de domaine golang.org.

C'est le problème, et une solution possible, de toute façon. Même si la solution n'est pas la bonne, cela ne veut pas dire que le problème n'existe pas.

Je vote $ HOME/groupe

Merci.

Pouvons-nous utiliser GOPATH par défaut comme ~/.gosrc ?

Pouvons-nous utiliser GOPATH par défaut comme ~/.gosrc ?

Celui-ci sera masqué par défaut sous Linux et OS X, et visible sous Windows. Quelle serait la motivation pour cacher GOPATH ?

La discussion sur la valeur de la valeur par défaut a eu lieu il y a un mois. La décision sur $HOME/go a été prise et est déjà mise en œuvre. Revenir à ce sujet ne fera que rendre le fil insupportablement long.

Les gens jouent au go et ont du code source pour jouer au go.

Je ne vous suis pas vraiment, mais étant donné que vous aurez réglé GOPATH sur
quelque chose d'autre déjà, il n'y aura aucun impact pour vous.

Le mercredi 26 octobre 2016 à 9h43, RalphCorderoy [email protected]
a écrit:

@davecheney https://github.com/davecheney , j'essaie d'empêcher ce que je
a dit il y a deux heures : #17262 (commentaire)
https://github.com/golang/go/issues/17262#issuecomment -256173981

Aller est un mot commun. J'ai eu un ~/bin/go. Les gens jouent au Go et ont le code source
à voir avec jouer au go. Nabbing ~/go par défaut quand il existe déjà juste
car il se trouve qu'il contient des src c'est impoli. Si ~/go n'existe pas alors Go
peut prendre le nom, créer le répertoire, le tamponner comme golang avec un
dotfile significatif, par exemple basé sur le nom de domaine golang.org.

C'est le problème, et une solution possible, de toute façon. Même si la solution
n'est pas la bonne, cela ne veut pas dire que le problème n'existe pas.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -256199766, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

Salut @davecheney , Ce problème a commencé lorsque vous avez proposé ~/gocode. Au fil du temps, c'est devenu ~/go. @robpike a dit ci-dessus "ce ne peut être un problème de choisir ce nom que si $HOME/go existe déjà, ce qui ne fera que plaisir aux experts qui ont déjà installé go et comprendront GOPATH". Je pense qu'en étant enveloppé de golang pendant si longtemps, vous oubliez collectivement à quel point un mot "aller" est courant et à quel point il a d'autres significations, comme le jeu de société.

Ce changement s'adresse aux nouveaux arrivants sur Go et certains d'entre eux pourraient déjà avoir ~/go pour une utilisation non-Go. Je suggère que si go arrive, découvre que GOPATH n'est pas défini et qu'aucun ~/go n'existe, il peut le créer, en saisissant le nom. Mais si ~/go existe, il ne devrait l'utiliser que s'il peut dire qu'il l'a créé dans une invocation antérieure sans GOPATH. J'ai suggéré qu'un dotfile soit créé comme ce drapeau. Vous avez dit que ~/go/src servira de drapeau. Mon objection est que src lui-même n'est pas rare parmi les programmeurs, c'est-à-dire ceux qui pourraient installer Go. Un fichier de points inhabituel, par exemple ~/go/.default-gopath évite ce conflit potentiel.

S'ils ont créé manuellement ~/go pour Go et exécuté go sans GOPATH, il n'utilisera pas ~/go car le fichier dotfile est manquant. Je pense que c'est OK car en commençant à configurer une installation Go, ils devraient continuer, en définissant GOPATH. Ce n'est pas le simple cas "install package, run go(1)" qui est ciblé.

Si rien de tout cela n'est considéré comme un problème, alors c'est très bien. Mais tant que vous vous plaignez de ne pas comprendre mon point, je suis condamné à continuer d'essayer de l'expliquer.

C'est pourquoi j'ai initialement suggéré un chemin différent, avec la suggestion de Rob, c'est maintenant officiellement hors de mes mains.

Cela dit, je suis heureux que _a_ path ait été choisi car je vois cela comme le point de l'exercice.

En réponse à vos préoccupations, je vous recommande de suivre https://go-review.googlesource.com/#/c/32019/ où précisément le problème qui vous préoccupe est en cours de discussion.

@RalphCorderoy , votre souci est-il que les programmeurs de jeux de société

Rob et Russ sont très anti-dotfiles. Il est préférable d'énoncer le problème que d'énoncer la réponse si la réponse implique des fichiers dotfiles (ou des liens symboliques).

@bradfitz , oui, ~/go existe déjà pour les joueurs de gogame, et en outre ~/go/src existe car ce sont des joueurs de gogame programmeurs, sinon ils ne joueraient pas avec Go. (J'ai ~/chess/src en l'occurrence.)

la logique de résumé d'adg https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c semble bien, et je suis en faveur de la création de ~/go s'il n'existe pas, mais test -d ~/go/src est un test approximatif pour utiliser ~/go s'il n'y a pas de GOPATH.

Si ce n'était pas ~/go, mais quelque chose de plus inhabituel, comme la suggestion originale de Dave, alors cela n'aurait pas d'importance. Je pense que les sondages sur ce qui est actuellement utilisé et qui ont montré que ~/go était très populaire ne sont pas très utiles lorsque les électeurs sont des programmeurs Go suffisamment désireux de suivre les problèmes et les médias sociaux.

@RalphCorderoy Je pense que la quantité de soins et de sous-vêtements doubles conçus dans CL 32019 est plus que suffisant pour le désagrément potentiel du petit groupe de programmeurs de jeux de go qui _n'ont pas_ utilisé Go avant la version 1.8 et _n'ont pas_ mis GOPATH _et_ commencent également à apprendre le Go, la langue.

L'outil go ne va pas supprimer ou corrompre le code non go qu'il rencontre, vous obtiendrez juste un message légèrement déroutant dans quelques situations. Pour expliquer cela, l'outil go ne construira pas la source Go en haut de $GOPATH/src car ce code ne se trouve pas dans un package importable. De plus, l'autre objectif de ce changement est de faciliter go get du code en fournissant un emplacement par défaut pour télécharger la source, donc _si_ il y avait le code source du jeu de go dans ~/go/src , les chances qu'il entre en conflit avec un sous-répertoire dérivé d'un référentiel go gettable sont très faibles, et même si cela devait se produire, l'outil go ou git s'effondrerait avant que les données ne soient modifiées.

Je pense que la situation qui vous préoccupe est très improbable, et encore atténuée par l'explication ci-dessus.

(Juste un argument vraisemblablement valable contre GOPATH=$HOME ) : les performances de goimports sont-elles .goimport_ignore . Sinon, les performances des éditeurs populaires pourraient en souffrir.

Ainsi, GOPATH!=$HOME est probablement une option sans collision/non polluée et devrait être performante.

@davecheney Après go get j'aurais des conneries à effacer de ~/go/{bin,src,pkg} et ce ne serait pas une bonne introduction à Go après avoir collé la ligne que j'ai trouvée sur Internet.

@RalphCorderoy s'il vous plaît, comprenez que l'objectif de ce changement est de faciliter la tâche aux nouveaux utilisateurs de Go - ce n'est pas vous - vous avez déjà défini $GOPATH, car vous devez le faire avec chaque version de Go à partir de 1.1. Le chevauchement entre les utilisateurs de go-the-game et les utilisateurs potentiels de go-the-programming-language est très très faible. Je ne pense pas qu'il y aura de problème.

@RalphCorderoy La situation que vous décrivez est rare, et toute personne exécutant des commandes shell à partir d'un site Web aléatoire ne devrait pas s'attendre à ce que ses disques ne soient pas effacés, sans parler de certains fichiers téléchargés et mélangés dans un répertoire éponyme. (Modifier : envisagez de créer et de modifier automatiquement .wine dans le répertoire personnel de l'utilisateur. Et si l'utilisateur a quelque chose d'autre là-bas ? Après tout, « vin » est un terme que nous utilisons pour une boisson particulière.)

La collision de noms entre "Go" la langue et "Go" le jeu de société est certainement comprise et bien connue. Le système de fichiers est une ressource partagée, les collisions se produisent et sont inévitables.

@davecheney , S'il vous plaît, arrêtez de me dire que ce changement ne vise pas à m'aider car je ne suis pas un nouvel utilisateur de Go. J'en ai toujours été conscient avant même que vous ne commenciez à le souligner. Je comprends également que votre position est len(intersect(existing-~/go, GOPATH-less)) est trop petite pour être préoccupante.

Après avoir nettoyé le go-get cracher dans ~/go parce qu'il saurait ce qui n'était pas normalement là, il devrait alors faire des recherches pour voir ce que la ou les commandes auraient pu faire sous $HOME au cas où plus un nettoyage était nécessaire.

Se désabonner

Je suis désolé si je vous ai offensé. je ne souhaite plus correspondre
avec vous sur cette question. Merci.

Le vendredi 28 octobre 2016 à 03h28, RalphCorderoy [email protected]
a écrit:

@davecheney https://github.com/davecheney , s'il vous plaît arrêtez de me dire ça
change n'a pas pour but de m'aider car je ne suis pas un nouvel utilisateur de Go. j'ai
toujours été conscient de cela avant même de commencer à le souligner. moi aussi
comprendre que votre position est len(intersect(existing-~/go, GOPATH-less)) est
trop petit pour être préoccupant.

Après avoir nettoyé le go-get cracher dans ~/go parce qu'il saurait quoi
n'était pas là normalement, il devrait alors faire des recherches pour voir quoi d'autre
la ou les commandes peuvent avoir été effectuées sous $HOME au cas où un nettoyage supplémentaire serait nécessaire.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/17262#issuecomment -256697043, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

Davecheney, Non, pas d'infraction. Cela ne sert à rien de continuer à couvrir le même terrain.

Je me demandais juste - quel est le comportement attendu si $HOME n'est pas défini ?

Bien que je n'aie jamais travaillé sur un système où c'était le cas, il semble possible que quelqu'un ait modifié ses variables d'environnement par défaut pour une raison quelconque, et ce cas limite doit être traité de manière cohérente.

Je pense qu'il évalue actuellement $GOPATH='' ; cela signifie-t-il qu'il va utiliser le répertoire de travail actuel ?

utiliser le répertoire de travail courant

Il m'est venu à l'esprit que cela pourrait être le plus utile pour un nouvel utilisateur de Go qui n'a pas défini GOPATH. Un go get serait similaire à un wget, etc., remplissant le répertoire courant. Ils ne sont pas intéressés par l'aspect chemin de GOPATH à ce stade, et veulent très probablement que chaque tentative de jouer avec différents éléments en ligne soit distincte, comme le leur donnerait un nouveau répertoire temporaire de leur propre fabrication. Ils peuvent obtenir, exécuter et supprimer facilement les différents dépôts qu'ils voient référencés.

• si GOPATH n'est pas défini :
  
  
  
  • si seulement un ou deux, mais pas tous, de ~/{bin,pkg,src} existent :
  
  
  • ils doivent définir GOPATH, pkg est l'inhabituel
  
  
  • sinon tout ou rien n'existe :
  
  
  • s'assurer qu'ils existent tous
  
  
  • GOPATH=$(pwd)
  
  

J'ai des sentiments mitigés à ce sujet, mais mon sentiment dominant (en tant que personne qui a défini $GOPATH ) est que le comportement de go get devrait être "déterministe" et toujours installer des choses sous $GOPATH - une destination cohérente et bien documentée.

Même si je ne suis pas affecté par ce changement, il me semble étrange que go get télécharge des éléments à différents emplacements en fonction du répertoire de travail lorsque la commande est émise. Je suis conscient que c'est ce que font wget , npm install , et d'autres outils, mais cela ressemble à un écart par rapport à l'idée d'une $GOPATH cohérente de

Si cela dépasse le cadre de ce problème, je proposerais simplement de quitter et de générer une erreur si $HOME n'est pas défini.

J'ai enseigné à 5 nouveaux programmeurs venus du monde Java dans un pays du tiers monde. Ils étaient tous confus à propos de GOPATH. Zut, je l'étais aussi quand j'ai commencé avant la sortie de Go 1. Personnellement, j'utilise "$HOME/gopath" mais je suggère que la commande "go get" les dirige vers un blog go qui est CLAIRE sur la façon de créer un chemin go pour leur système d'exploitation. C'est tout ce dont nous avons besoin. Quelques conseils par la commande "go get" qui n'est pas une spécification .. Mais un sacrément simple article de blog !!

Évidemment, je veux dire quand aucun GOPATH n'a été défini. Il suffit de mettre à jour le message d'erreur qui s'affiche actuellement. Le taux d'adoption est déjà là. J'ai juste besoin d'un peu d'aide au lieu de la méthode google it up actuelle que font les nouveaux arrivants.

@einthusan J'ai l'impression que c'est assez bien documenté sur https://golang.org/doc/code.html#GOPATH , mais je ne sais pas combien de personnes qui débutent avec Go lisent réellement cette page.

Désolé de spam.. Après avoir fait quelques recherches sur Google.. Je pense que "aller chercher" devrait simplement demander à l'utilisateur de dire "Aucun GOPATH n'a été défini... Souhaitez-vous utiliser le répertoire de travail actuel comme GOPATH temporaire?" (Oui Non)

@einthusan , il n'y a pas de précédent pour que cmd/go fasse des invites interactives.

Si le nouveau GOPATH par défaut est $HOME/go. Les gens ne s'attendraient-ils pas à ce que https://hub.docker.com/_/golang/ adopte le même comportement ?

@cescoferraro c'est une question pour les mainteneurs de cette image. Bien qu'il soit étiqueté comme "officiel", ce projet n'est pas affilié à Go.

Répondre/répondre à ma propre question sur unset $HOME :

Dans l'implémentation actuelle (la CL est liée ci-dessus), $GOPATH défaut est "" si $HOME n'est pas défini : https://go-review.googlesource.com/#/ c/32019/11/src/go/build/build.go Je pense que cela est cohérent avec le comportement actuel.

Je pense que ce cas limite est très improbable car $HOME est toujours défini dans une session de connexion normale, ce qui est probablement le cas pour la plupart des programmeurs Go. Bien que j'aimerais personnellement que le comportement soit explicitement clarifié, il semble qu'il n'y ait pas d'"effets secondaires" (comme l'installation de choses dans le répertoire de travail). Corrige moi si je me trompe. :)

Si cela doit être plus facile pour les personnes qui commencent avec Go pour la première fois, que ce soit quelque chose comme le chemin actuel :

GOPATH=$(pwd)

La configuration de export GOPATH=$(pwd) facilite le passage d'un projet à l'autre

Mon comportement proposé pour ce changement:

Variables d'environnement

• Si GOPATH est défini, les outils se comportent comme ils l'ont toujours fait
• Sinon, on vérifie la variable d'environnement HOME ( home pour plan9, USERPROFILE pour windows).
  
  
  
  • Si cette variable d'environnement n'est pas définie, alors GOPATH ne sera pas défini non plus : cela signifie que "go get" échouera avec cannot download, $GOPATH not set.
  
  

> unset GOPATH
> unset HOME
> go env GOPATH

• Sinon, GOPATH sera défini comme $HOME/go ( $home/go , %USERPROFILE%\go ).

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

Création GOPATH

Actuellement, si $GOPATH n'existe pas, il est créé lorsque nous exécutons go get import/path . Cela ne changera pas.

Le seul changement est que si $GOPATH n'est pas défini dans l'environnement utilisateur (c'est-à-dire que echo $GOPATH n'affiche aucune valeur), une vérification supplémentaire est effectuée pour s'assurer que la valeur par défaut est acceptable :

• si GOPATH n'est pas défini et qu'aucune valeur par défaut n'a été créée : la commande échouera

> 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'
👎

• si le $GOPATH par défaut n'existe pas, un avertissement sera affiché expliquant que le répertoire a été créé, pointant vers go help gopath pour plus d'informations.

> 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
👍

• si le $GOPATH par défaut existe :
  
  
  
  • et ce n'est pas un répertoire : la commande échouera (comme avant)
  
  

> 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
👎

• et c'est soit un répertoire vide, soit un répertoire qui a un sous-répertoire nommé src la commande réussira (pas d'avertissements)

> 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
👍

• et c'est un répertoire non vide sans sous-répertoire nommé src la commande échouera

> 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
👎

Ainsi, seul un nouvel avertissement est inclus chaque fois qu'un répertoire est créé à l'aide d'un GOPATH par défaut.

@campoy la proposition de comportement est superbe.

Mais encore une fois, en tant qu'utilisateur avancé, je veux savoir combien d'entre nous utilisent sérieusement $HOME/go comme GOPATH quotidiennement ? Je pensais même qu'il devrait peut-être y avoir une commande go pour définir le GOPATH comme pour démarrer un environnement virtuel sur un répertoire de travail python.

Comme je travaille sur plusieurs projets, je fais généralement quelque chose comme ça :

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

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

@jinmatt
Ce changement ne modifie que le comportement de GOPATH non défini, c'est la portée du changement.
La communauté est déjà parvenue à un accord sur $HOME/go.

Si vous n'aimez pas $HOME/go , définissez simplement GOPATH sur la valeur que vous préférez (par exemple, $HOME dans mon cas).

Merci pour le croquis de conception.

1. Puisque nous avons maintenant établi que GOPATH ne sera créé que pendant 'go get', n'affichons les messages que si l'indicateur -v est donné, cohérent avec le reste du comportement 'go get -v'.
2. Si le répertoire est créé, le message doit être au plus

# créé GOPATH=/users/campoy/go; voir 'allez aider gopath'

Ce n'est pas un avertissement : les avertissements sont mauvais. D'un autre côté, si la création échoue, vous voudrez peut-être imprimer

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

Ces deux messages peuvent être imprimés, que GOPATH soit inféré ou défini explicitement.

1. Les heuristiques concernant le répertoire vide et le sous-répertoire src sont trop complexes. Pire encore, ils s'attaquent à des problèmes hypothétiques, et les hypothèses sont très difficiles à concevoir. Mieux vaut avoir un comportement plus simple et plus prévisible. Pour commencer, je pense qu'il est logique de ne pas avoir de règles, jusqu'à ce qu'il y ait des exemples concrets de problèmes réels. Les gens auront le temps de signaler des problèmes pendant les bêtas et de libérer les candidats. Définissons simplement GOPATH=$HOME/go (à condition que $HOME soit défini).

Edit: prétendez que la démarque Github n'a pas complètement gâché cela.

@campoy En ce qui concerne le src/ , quel est le comportement actuel de go get lorsqu'un GOPATH est défini mais qu'aucun répertoire src n'existe ? Y a-t-il une bonne raison de ne pas le créer également ?

Il semble juste plus simple d'expliquer si $HOME/go/src est créé au premier coup (ou $GOPATH/src si cette variable d'environnement est définie)

Aujourd'hui, lorsque GOPATH est défini, les répertoires nécessaires sont créés, inconditionnellement, selon les besoins.

CL https://golang.org/cl/33356 mentionne ce problème.

CL https://golang.org/cl/33730 mentionne ce problème.