Go: cmd / go: asume GOPATH = $ HOME / go si no está configurado

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

Me gusta, pero ¿tenemos alguna preferencia específica por "gocode" y no algo como "gopath"?

¿Cuántas personas ya usan GOPATH = $ HOME / gocode? Me parece que no son muchos. Eso sugiere que es el valor predeterminado incorrecto.

"gocode" tendrá un motor de búsqueda y otras confusiones con la popular herramienta github.com/nsf/gocode.

¿Tenemos alguna información sobre lo que hace la mayoría de la gente?

Yo mismo uso GOPATH = $ HOME / gopath.

Aprobado aquí si actualmente usa GOPATH = $ HOME

Aprobado aquí si actualmente usa GOPATH = $ HOME / gopath

Aprobado aquí si actualmente usa GOPATH = $ HOME / gocode

¿Debo hacer una encuesta de Twitter en @golang?

@campoy , suena bien. Probablemente sea mejor que invitar a todos a este error.

¿Qué tal $ HOME / go (que es lo que uso)?

Véase también: http://go-talks.appspot.com/github.com/freeformz/talks/20160712_gophercon/talk.slide#7

$ CASA: 8,9%
$ INICIO / ir: 50,6%
Otro: 40,5%

Realmente desearía haber dividido más opciones para este.

Se inició la votación: https://twitter.com/golang/status/781189567437164544

El miércoles, 28 de septiembre de 2016 a las 10:51 a. M. Edward Muller [email protected]
escribió:

¿Qué tal $ HOME / go (que es lo que uso)?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -250244110, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

Consulte también la columna I aquí: https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid = 1525640201

@freeformz ,

$ HOME / go está en conflicto con la ruta. El código fuente de go (go.googlesource.com/go) suele consultarse. Es malo que la comunidad haya bendecido esta ubicación como predeterminada para GOPATH :( Me preocupa que si alguien se olvida de configurar su GOPATH y ejecuta la herramienta go, estropeará su directorio de desarrollo actual.

@rakyll para cada uno, solo quería indicar lo que yo y muchos otros usamos. go.googlesource.com/go está registrado en /usr/local/go.git en mi sistema.

¿Cuántas personas ya usan GOPATH = $ HOME / gocode? Me parece que no son muchos. Eso sugiere que es el valor predeterminado incorrecto.

Para que conste, utilizo GOPATH=$HOME , pero sentí que esto sería demasiado polémico y restaría valor al objetivo de esta propuesta, que es mejorar la experiencia del nuevo usuario.

@freeformz , supongo que no tenemos que preocuparnos por las rutas canónicas existentes que están fuera de $ HOME. El valor predeterminado para GOPATH estará en $ HOME en algún lugar y el requisito mínimo debería ser que no entre en conflicto con ninguna ruta crítica existente.

$ HOME / gocode me suena extraño, pero podría ser una muy buena elección.

El punto es que importa menos cuál es el valor predeterminado, solo que hay uno.

No importa cuál sea el valor predeterminado, porque establecer este valor predeterminado esencialmente hará que todos los nuevos en Go estén trabajando dentro de unos años.

El comando go hace todo lo posible para no confundirse cuando GOPATH = $ GOROOT explícitamente; Estoy seguro de que se puede aplicar la misma lógica a una configuración implícita. Así que no me preocupa demasiado destrozar $ HOME / go accidentalmente.

Todavía me pregunto si en lugar de un valor predeterminado fijo deberíamos rastrear automáticamente los padres del directorio actual para averiguar dónde está GOPATH. Esto es lo que hacen muchas herramientas de origen en estos días (por ejemplo, todos los sistemas de control de versiones), por lo que es un concepto que la gente entendería. Y no los obliga a usar un nombre de directorio o tener solo un espacio de trabajo GOPATH. Pero también podríamos tener esa discusión sobre el tema original.

@rsc Me encantaría que el valor predeterminado sea GOPATH=$HOME porque eso significa que $GOPATH/bin estarán en su camino (al menos en la mayoría de las distribuciones de Linux, no estoy seguro de darwin).

$GOPATH=$HOME/go también es una buena opción y aquellos que tengan la fuente del compilador revisada allí ya habrán configurado GOPATH=something else por lo que no hay posibilidad de conflicto.

Para ser claros, no estaba tratando de ser frívolo cuando dije

El punto es que importa menos cuál es el valor predeterminado, solo que hay uno.

Más bien, tratar de enfatizar el objetivo de esta propuesta es que la herramienta go use un valor predeterminado de $GOPATH cuando no se proporciona uno, ya que esto es una fuente continua de confusión y frustración para muchos recién llegados al idioma.

Estoy 👎 en el rastreo automático porque falla en un caso de uso importante, que es:

1. Instalé Go, en realidad no leí los documentos de instalación de Go, solo seguí lo que decía en el README del repositorio que decía brew install go
2. He corrido go get github.com/thething/theproject
3. Ahora me sale un error acerca de no configurar $ GOPATH. ¿Que es eso? ¡Solo quería ejecutar este programa sobre el que alguien tuiteó!

Un valor predeterminado de GOPATH=$HOME/go SGTM, suponiendo que decidamos por un enfoque predeterminado y no de detección automática.

El comando go hace todo lo posible para no confundirse cuando GOPATH = $ GOROOT explícitamente; Estoy seguro de que se puede aplicar la misma lógica a una configuración implícita.

Suena genial.

no estoy seguro de darwin

No en Darwin.

Si esto es para recién llegados, desaconsejaría GOPATH=$HOME ya que eso crearía tres directorios en su directorio de inicio en lugar de solo uno. No me gusta el software que contamine mi directorio personal más allá de lo necesario.

@mvdan lo entiendo y tu reacción fue por qué no GOPATH=$HOME .

Si _yo_ personalmente quiero establecer mi GOPATH en $HOME , entonces esa opción permanecería disponible para mí, y no tendría que hacer cambios si esta propuesta fuera aceptada para Go 1.8.

@davecheney

predeterminado a un valor de GOPATH = $ HOME / gocode

No hay una variable HOME predeterminada en Windows. ¿Qué propones hacer en Windows?

Me encantaría que el valor predeterminado sea GOPATH = $ HOME porque eso significa que $ GOPATH / bin estará en su camino

Siempre me preocupa tener $ GOPATH / bin en mi PATH. go get instala los programas de otras personas allí. ¿Realmente queremos que los nuevos usuarios de Go instalen programas aleatorios de Internet en algún lugar de su RUTA?

Alex

No soy un usuario de Windows experimentado, pero supongo que existe una noción de una ruta base donde se almacenan los documentos y la configuración. Para el propósito de esta discusión, suponga que estoy hablando de esa ruta en el contexto de los usuarios de Windows.

Si no existe tal ruta, asuma C: / gocode.

Wrt a mi comentario sobre GOPATH = $ HOME, aunque esto es y seguirá siendo mi preferencia personal, reconozco que esta es una opción contenciosa para un valor predeterminado y, como tal, no lo sugerí como el valor propuesto.

La detección automática está plagada de peligros. Comencé a hacer prototipos de esto hace un tiempo, pero agregó una complejidad significativa tanto a la herramienta Go como a la experiencia del usuario.

No estoy al tanto de lo que ha estado sucediendo con el grupo de trabajo de administración de paquetes, pero puedo imaginar un futuro no muy lejano en el que GOPATH se elimine por completo.

Dicho esto, incluso si GOPATH desaparece en algún momento en el futuro cercano, aún puede ser útil establecer un valor predeterminado. Si creemos que es probable que GOPATH desaparezca, no importa demasiado en qué lo establezcamos.

Por lo que leí arriba, hay cierto consenso de que:

1. De forma predeterminada, GOPATH=$HOME es demasiado invasivo.
2. El valor predeterminado debe incluir la cadena go algún lugar (probablemente como prefijo).

No me preocupa que GOPATH sea un clon del repositorio principal de go (es decir, GOPATH == GOROOT). Es probable que las personas que revisan el repositorio go tengan un conjunto GOPATH. La herramienta Go detectaría el conflicto de todos modos, como lo hace hoy.

Con eso en mente, el valor predeterminado más sucinto sería $HOME/go , que creo que es bastante razonable.

Supongo que existe una noción de una ruta base donde se almacenan los documentos y la configuración.

No conozco tal cosa. Quizás otros usuarios de Windows comentarán aquí.

Si no existe tal ruta, asuma C: / gocode.

En su lugar, desea C: gocode.
Poner cosas en la raíz de C: \ no me suena bien. ¿Recomendaría que GOPATH se establezca en / gocode en Linux?
Pero, dado que el instalador de Windows ya instala Go en C: go, C: gocode para GOPATH es al menos consistente.

Alex

Pero, dado que el instalador de Windows ya instala Go en C: go, C: gocode para GOPATH es al menos consistente.

¿No debería proporcionarse GOPATH para cada usuario? Para ser lo mismo que UNIX, %USERPROFILE%\gocode , supongo.

Go + encuesta en https://goo.gl/xAsgEj

después de usar durante mucho tiempo algo como $ HOME / go-Programs, cambié GOPATH a $ HOME. entonces, ahora tengo la siguiente estructura:

$ INICIO / contenedor
$ INICIO / paquete
$ INICIO / src /
$ HOME / src / github.com / user / some_github_project
$ HOME / src / algún_proyecto

esta estructura es más genérica y también se puede usar para usar con otros lenguajes o proyectos y con github. por ejemplo, tengo $ HOME / src / starts (léelo en casa / fuentes / conversaciones para archivos de rebajas) u otros proyectos en algunos idiomas (como $ HOME / src / github.com / user / html) pero también fuentes y tengo uno lugar para muchas fuentes de proyectos con o sin correspondencia github.

bin o pkg puede considerarse desordenado, pero creo que no es tan molesto. Es más complicado tener muchas carpetas de origen para personas que usan varios idiomas.

entonces, desde mi punto de vista, el mejor lugar de GOPATH es $ HOME.

Estoy usando $ HOME / gocode como mi GOPATH.
Estoy en contra de $ HOME / go ya que a veces no tienes el privilegio de root y necesitas instalar Go en tu directorio de inicio. En tal caso, creo que $ HOME / go sería lo mejor para GOROOT.
Entonces deberíamos usar algo diferente de $ HOME / go como GOPATH.

@hnakamur Cuando instalé Go manualmente (ahora usando Ubuntu Make), lo puse en $ HOME / bin / go - $ {go_version} (con un enlace simbólico de $ HOME / bin / go to $ HOME / bin / go- $ {version} / bin / go, así que no tuve que editar mi $ PATH)

@tbroyer Es un nicho. Supongo que la mayoría de los usuarios no quieren configuraciones o ajustes adicionales. En mi opinión, ~ / bin ya se usa para poner su propio script o binarios (como yo). Y creo que ~ / bin (~ / src, ~ / pkg) dificultan la eliminación de los binarios go.

Uso $ HOME para mi GOPATH.
¿Por qué configurar automáticamente GOPATH, por qué no generar una advertencia con buena información sobre cómo configurarlo si GOPATH no existe?

¿Por qué configurar automáticamente GOPATH, por qué no generar una advertencia con buena información sobre cómo configurarlo si GOPATH no existe?

El problema no es que la gente no sepa cómo configurar una variable de entorno (en su mayor parte), es que incluso si lo hace, se siente mal tener que pasar por obstáculos para comenzar a usar Go. Ser capaz de usar Go fuera de la caja con los valores predeterminados razonables tan pronto como se instala hace que la experiencia sea lo más fluida posible, y significa que es probable que más personas realmente prueben Go después de descargarlo, en lugar de encontrar un obstáculo, perder el impulso y decidir que no vale la pena jugar con él.

Tiendo a estar de acuerdo con Chris y Andrew: si va a haber un GOPATH predeterminado, debería ser solo $ HOME / go, no gopath o gocode. La mayoría de los usuarios no tienen una distribución de Go comprobada (y todos los que la tienen hoy ya configuran GOPATH, por lo que esto no les molestará). El valor predeterminado debe tener sentido para los nuevos usuarios, no para los avanzados, y para la mayoría de los usuarios $ HOME / go tiene mucho sentido.

Jaana expresó su preocupación de que el comando go se confunda si $ HOME / go resulta ser una distribución de Go, pero el comando go ya comprueba si hay GOPATH = $ GOROOT accidental. Es fácil comprobar si eso es cierto cuando GOPATH también se establece implícitamente. De hecho, también sería fácil aumentar el cheque para buscar, digamos, $ HOME / go / src / cmd / go / alldocs.go, para evitar confusiones incluso cuando GOROOT! = $ HOME / go pero $ HOME / go lo hace contienen una distribución Go.

$ HOME / go no es una buena opción para GOPATH. hagamos un simple ejercicio de comportamiento ... los nuevos usuarios pueden considerar fácilmente el valor predeterminado como una mejor práctica. digamos que soy un usuario nuevo, ¿por qué debería considerar los valores predeterminados como algo malo? más que eso, el método más fácil (¿y el mejor?) para instalar golang es desempaquetar en $ HOME porque con este método el compilador siempre está en la última versión y no necesita derechos de root, por lo que puede suponer fácilmente que muchos usuarios tendrán el compilador go. en $ HOME / go. ¿Por qué debería mover el compilador en / usr / local cuando simplemente no lo hice?
más que eso, pueden hacer proyectos y pueden clonar proyectos en esta carpeta. por lo tanto, tendrán una carpeta desordenada y, con un poco de descuido, pueden eliminar fácilmente la carpeta de su proyecto con una nueva reinstalación de golang.
Además, los usuarios de Windows tienen c: go por defecto.

Me gusta $ HOME / gopath. Dice lo que es.
El primer resultado en Google para "gopath" es la página correcta.

Si se adopta un valor predeterminado, ¿podría agregarse una función func GOPATH() string a runtime ? En este momento, uno puede usar os.Getenv() , pero con un valor predeterminado no será tan simple.

@btracey , GOPATH es una lista, no un valor único. Utilice filepath.SplitList . Además, GOPATH no es una función del tiempo de ejecución. Solo concierne a cmd/go .

Para compatibilidad con versiones anteriores, probablemente necesitemos configurar GOPATH en el proceso '
entorno si no se establece ninguno.

El 30 de septiembre de 2016 a las 08:10, Brendan Tracey [email protected]
escribió:

Si se adopta un valor predeterminado, ¿podría agregarse una función de cadena func GOPATH ()
al tiempo de ejecución? Ahora mismo se puede usar os.Getenv (), pero con un valor predeterminado
no será tan simple.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -250605418, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

Tienes razón @bradfitz. La solución propuesta por @adg cumpliría con todos mis usos.

Esta es una arruga interesante. Puedo ver esto fallando actualmente cuando no
GOPATH está establecido, pero también cuando GOPATH contiene varios valores, y luego
hay un caso en el que la aplicación se basa en una máquina y se implementa en
otro.

No quiero descartar este uso de GOPATH, entiendo el dolor de
poder localizar archivos de soporte para su aplicación, pero me gustaría
para comprender cuán extendido es este uso y cómo el actual
las implementaciones tratan los problemas que destaqué anteriormente.

El viernes 30 de septiembre de 2016, a las 08:35 Brendan Tracey [email protected] escribió:

Tienes razón @bradfitz https://github.com/bradfitz. La solución
propuesto por @adg https://github.com/adg cumpliría con todos mis usos.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -250611813, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

Mi uso no es el normal. Hago investigación científica y me ha resultado muy eficaz no solo tener gopath/src y gopath/bin , sino también gopath/data y gopath/results . Esto facilita la copia de los archivos de origen en un nuevo sistema sin tener que copiar también los (gigabytes de) archivos de resultados. El nuevo sistema (digamos un clúster) genera nuevos archivos de resultados y puedo copiar esos resultados en una ubicación central. Es muy fácil decir gopath = os.Getenv("GOPATH") y guardar un archivo en algo como filepath.Join(gopath, "results", "projectname", result.json) .

Gracias. Para que quede claro, no quise dar a entender que su uso fuera incorrecto o
mal, solo quería entender este uso de GOPATH wrt para el
restricciones que destaqué.

El viernes 30 de septiembre de 2016, 09:09 Brendan Tracey [email protected] escribió:

Mi uso no es el normal. Hago investigación científica y he encontrado
es muy efectivo no solo tener gopath / src y gopath / bin, sino también
gopath / data y gopath / results. Esto facilita la copia de la fuente.
archivos a un nuevo sistema sin tener que copiar también los (gigabytes de)
archivos de resultado. El nuevo sistema (digamos un clúster) genera nuevos archivos de resultados,
y puedo copiar esos resultados en una ubicación central. Es muy fácil de
luego diga gopath = os.Getenv ("GOPATH") y guarde un archivo en algo como filepath.Join (gopath,
"resultados", "nombre del proyecto", resultado.json).

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -250617618, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

Aprobado aquí si actualmente usa GOPATH=$HOME/.go

@davecheney no se ofende, solo quería proporcionar suficiente contexto para ser útil.

Dejemos el uso de GOPATH para encontrar archivos de soporte fuera de esta discusión.

(GOPATH está destinado a ser una configuración de tiempo de compilación, no de tiempo de ejecución. Sé que la gente difumina estos a veces y usa GOPATH para encontrar archivos asociados en tiempo de ejecución, pero no creo que debamos fomentar eso o hacer es más fácil de hacer. Necesitamos una mejor historia para los archivos de soporte en general, pero eso debería ser un tema aparte).

Relacionado con la búsqueda de archivos asociados en tiempo de ejecución: # 12773

Lamento contaminar la discusión una vez más @rsc , pero @ randall77 , # 12773 es más difícil de usar que simplemente trabajar en este problema directamente. El código específico que necesita un archivo (o para guardar un archivo) puede moverse mucho, y quiero un lugar fijo para que las entradas / salidas vivan independientemente de (y separado de) la refactorización.

Este problema se trata de un posible valor predeterminado de GOPATH. No se trata de usos alternativos de GOPATH.

Si los usuarios objetivo de este cambio son solo aquellos que solo querían
instalar un nuevo programa escrito en Go, y no aquellos que realmente quieren
escribir Go, entonces, ¿qué pasa con ir a la clonación en un directorio por usuario en
$ TMPDIR y deje el binario en $ PWD si $ GOPATH no está configurado? (Obviamente
esto solo tiene sentido para go get import.path / for / a / command, si no es un
comando, go get debería fallar sin que se establezca $ GOPATH)

Para el forastero, esto tiene mucho sentido, al igual que obtener un archivo.

Una vez que el usuario quiera comenzar a escribir código Go, debe aprender a configurar
GOPATH correctamente.

Estoy en contra de $ HOME / go ya que a veces no tienes el privilegio de root y necesitas instalar Go en tu directorio de inicio. En tal caso, creo que $ HOME / go sería lo mejor para GOROOT.

Si está en un sistema Linux, yo diría que el mejor lugar para $ GOROOT podría ser $ HOME / .local / opt / go, no $ HOME / go, dependiendo de cómo interprete el propósito de $ HOME / .local , ya que solo $ HOME / .local / share (que parece reflejar / usr / local / share) se define en la especificación del directorio base de XDG: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest. html.

También se podría argumentar que el mejor valor predeterminado para GOPATH / GOBIN (en Linux) debería ser:
GOPATH = $ XDG_DATA_HOME / go, o $ HOME / .local / share / go
GOBIN = $ INICIO / .local / bin

Sin embargo, ¿probablemente eso no sea lo más fácil de entender para los nuevos usuarios? Y tampoco quedaría claro cuál es el mejor enfoque en Windows. $ HOME / go y $ USERPROFILE / go parecen pragmáticos.

Por favor, _por favor_ no dejemos que este hilo se convierta en una discusión sobre los nombres de las rutas canónicas de Linux y las ubicaciones de almacenamiento. No es productivo y creo que esta discusión ya se ha alejado bastante de la publicación original de Dave Cheney.

Tampoco estoy seguro de que la ubicación absoluta real importe tanto, creo que todo lo que este hilo realmente necesita decidir es "¿queremos un Gopath predeterminado?" (suena como un sí más o menos abrumador) y "¿debería ser compartido en todo el sistema o local para el usuario?" (hasta ahora, la mayor parte de la discusión ha sido sobre local). Después de eso, quienquiera que implemente puede elegir $HOME/gocode o $HOME/go o /usr/share/go/ o lo que desee que parezca razonable para quien revise el PR, y las cosas probablemente seguirán yendo bastante bien.

Creo que un GOPATH en todo el sistema no se puede iniciar debido a problemas de permisos.

El camino ancho del sistema es, para bien o para mal, GOROOT, que distribuciones
como Debian está usando para instalar paquetes "en todo el sistema", para mejor o para
peor.

Un GOPATH de todo el sistema está fuera del alcance de esta propuesta, esta propuesta
recomienda una ruta derivada del valor del usuario que inició sesión.

El martes 4 de octubre de 2016, a las 08:52, Andrew Gerrand [email protected] escribió:

Creo que un GOPATH en todo el sistema no se puede iniciar debido a problemas de permisos.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -251238251, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

Por favor, no dejemos que este hilo se convierta en una discusión sobre los nombres de las rutas canónicas de Linux y las ubicaciones de almacenamiento. No es productivo

Está bien, no lo hagamos. Mi punto principal fue realmente señalar otra razón por la que $ HOME / go probablemente no sea problemático como predeterminado de GOPATH, ya que probablemente no sea la ruta más "idiomática de Linux" para las instalaciones de usuarios locales de Go (también conocido como GOROOT) de todos modos.

Aparte de eso, creo que se ha discutido antes sobre el uso de XDG_CACHE_HOME para un GOPATH predeterminado, por lo que mencioné XDG_DATA_HOME, aunque no sé qué función desempeñan los autores del documento vinculado, o qué tan "oficial" es. .

$ CASA / trabajo .......

@adg @quentinmit @rsc ¿

Realmente me encantaría ver que sucediera algo aquí. es un punto de dolor frecuente en mis clases. Cualquier valor predeterminado (incluso $ home / go con el que no estoy de acuerdo :)) es mejor que ninguno.

$ HOME / ya estará. No existe una única respuesta mejor, pero esta es breve y sencilla, y solo puede ser un problema elegir ese nombre si $ HOME / go ya existe, lo que solo agradará a los expertos que ya hayan instalado go y entenderán GOPATH.

¿Quién quiere hacer el trabajo?

Definitivamente estaría feliz de trabajar en esto.

@campoy , ¿puedes hacerlo <= este viernes?

Yo diría que sí @bradfitz . No parece una gran cantidad de código por hacer.
Puedo empezar mañana.

actualización: Eché un vistazo rápido a esto y ya escribí un código, agregaré algunas pruebas y enviaré un cambio más tarde hoy

¡Esto es genial, chicos! 👍

@robpike ¿consideraste también mi propuesta alternativa en # 17271? Me gustaría entender por qué esta propuesta se consideró mejor

No será una buena idea tener los mismos nombres del directorio de instalación de Go y del directorio del espacio de trabajo, es decir, go porque:

1) Es muy fácil para un usuario ingenuo corromper / contaminar el espacio de trabajo si el usuario hace tar -xzf go$VERSION.$OS-$ARCH.tar.gz en el directorio de inicio

2) La experiencia predeterminada de un nuevo usuario cuando no está instalando en /usr/local (no quiere instalar como root) no será fluida ya que este será el flujo:
Descarga go $ VERSION. $ OS- $ ARCH.tar.gz
tar -xzf go$VERSION.$OS-$ARCH.tar.gz -> se instala en $ HOME / go
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something -> lanza cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

@krishnasrinivas tengo entendido que si GOROOT=$HOME/go , este valor predeterminado no se llevará a cabo o se producirá go error GOROOT y GOPATH no pueden ser lo mismo. En tales casos, como se dijo antes, se espera que el usuario sea lo suficientemente capaz de configurar su propio GOPATH .

@mvdan correcto, para los nuevos usuarios que no quieren usar privilegios de root para la instalación (y por lo tanto hay una alta probabilidad de instalar Go in ~ / go) no estamos facilitando que las cosas estén en funcionamiento, ya que tendrán que hacerlo explícitamente. establezca GOPATH en otra cosa. Esto se puede solucionar fácilmente si GOPATH predeterminado es ~ / gopath o ~ / gocode

Para la instalación no root, si los nuevos usuarios tienen que aprovechar GOPATH = ~ / go predeterminado, entonces la documentación de instalación debe complicarse un poco más pidiendo explícitamente a los usuarios que usen la opción tar -C para no instalarla en ~/go

@rasky considero el # 17271 y esta propuesta como ortogonal. La resolución de esta propuesta es una victoria fácil que no nos empuja en ninguna dirección en particular. Daré más detalles sobre ese tema.

Estoy de acuerdo con @krishnasrinivas. No tenía permisos de root, así que simplemente no empecé a ir a $ HOME / go. También configuré mi $ GOPATH = $ HOME / gowork.

@krishnasrinivas @joegrasse No existe una solución perfecta. Es fácil configurar GOPATH usted mismo, y espero que eso sea lo que hará la mayoría de la gente. El problema aquí es qué debemos hacer por las personas que son las más nuevas en Go. En general, no se trata de personas que están instalando su propia distribución de Go en ubicaciones personalizadas. Las personas que pueden descubrir cómo instalar Go en una ubicación personalizada pueden descubrir cómo configurar GOPATH .

Piense en lugar de una clase de programadores nuevos que estén usando distribuciones Go preinstaladas. Queremos que puedan empezar a escribir código Go. No queremos que el primer paso sea "esto es lo que es una variable de entorno. Así es como se establece una. Ahora establezca GOPATH en esto". Esos pasos no tienen nada que ver con Go como tal.

Una vez más, no existe una solución perfecta, pero parece prudente elegir algo.

@ianlancetaylor Estoy completamente de acuerdo en que se debe elegir algo. Solo creo que con go untaring to ./go, por defecto en $ HOME / go, podría no ser la mejor opción.

@ianlancetaylor GOPATH = $ HOME / gopath es un mejor valor predeterminado que GOPATH = $ HOME / go debido a las razones antes mencionadas.

No creo que el nombre actual sea un problema: si sabe cómo configurar PATH para una ubicación personalizada de go / bin en su homedir, sabe cómo configurar GOPATH.

@joegrasse @krishnasrinivas Eche un vistazo a " Instalación en una ubicación personalizada ".

Si está desmarcando en cualquier otro lugar que no sea /usr/local/go , por motivos de permisos o de otro tipo, es necesario configurar GOROOT también o compilar desde la fuente.

Siempre que ese sea el caso, no hay ningún beneficio en usar $ HOME / gopath, etc. sobre el $ HOME / go propuesto.

Supone que los nuevos usuarios prefieren instalar desde tar.gz. Puedo citar no
números, pero cree que su respuesta se basa en instalaciones de Linux, que
son el tercer destino de instalación más popular para go.

El martes, 25 de octubre de 2016, 20:28 Krishna Srinivas [email protected]
escribió:

@mvdan https://github.com/mvdan correcto, para usuarios que no quieren
use privilegios de root para la instalación (y por lo tanto, una alta probabilidad de instalar
Go in ~ / go) no facilitamos que las cosas funcionen como
tendrán que establecer explícitamente GOPATH en otra cosa. Esto puede ser
se soluciona fácilmente si GOPATH es ~ / gopath o ~ / gocode

Para la instalación no root, si los nuevos usuarios tienen que aprovechar la
GOPATH = ~ / go, entonces la documentación debe hacerse un poco más complicada
pidiendo explícitamente a los usuarios que utilicen la opción tar -C para no instalarla en
~ / ir

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -255984498, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

Todos los documentos también deben actualizarse. Probablemente sea la mayor parte del trabajo.

El 25 de octubre de 2016 a las 10:14, Francesc Campoy [email protected]
escribió:

Yo diría que sí. No parece una gran cantidad de código por hacer.
Puedo empezar mañana.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -255892314, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

Yo diría que sí. No parece una gran cantidad de código por hacer.
Puedo empezar mañana.

El lunes, 24 de octubre de 2016 a las 4:05 p.m. Brad Fitzpatrick [email protected]
escribió:

@campoy https://github.com/campoy , ¿puedes hacerlo antes del <= este viernes?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -255890668, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

Puedo ayudar con los documentos si es necesario. El único problema es que el material actual depende únicamente de GOPATH como punto de referencia. Por ejemplo,

"O, como ha agregado $GOPATH/bin a su PATH , simplemente escriba el nombre binario:"

o

"Crear paquete en GOPATH, mkdir -p $ GOPATH / src / github.com / user / hello"

Sin involucrarse con GOPATH y aprender qué es, es casi imposible hacer algo en Go que no sea obtener paquetes de terceros. Si podemos informar la ruta predeterminada a través de go env , sería fácil consultar eso en los documentos.

¿Quizás $ HOME / go / ... podría sustituirse en su lugar (o el equivalente en Windows)?

Como ha agregado $HOME/go/bin a su RUTA (o $GOPATH/bin si GOPATH está configurado) ...

Quizás en algún momento la documentación podría esperar que las personas no solo establezcan la variable de entorno PATH, sino que también establezcan GOPATH en $ HOME / go. Aunque es redundante, prepara al usuario para futuras referencias a GOPATH.

La documentación inicial podría asumir las variables de entorno predeterminadas y no mencionar en absoluto.

Supone que los nuevos usuarios prefieren instalar desde tar.gz. Puedo citar no
números, pero cree que su respuesta se basa en instalaciones de Linux, que
son el tercer destino de instalación más popular para go.

Tienes razón, mi opinión está sesgada hacia las instalaciones de Linux. Puedo ver que para los nuevos usuarios que instalan go en / usr / local, ~ / go podría ser un nombre de directorio más reconocible que ~ / gopath

La documentación inicial podría asumir el valor predeterminado y no mencionar
variables de entorno en absoluto?

Sí, es de esperar que todo el debate que distrae sobre la configuración de GOPATH se pueda mover
a un apéndice de la documentación de instalación, simplemente hagamos para GOROOT
en la actualidad.

El miércoles 26 de octubre de 2016, 06:01 Nathan Youngman [email protected] escribió:

Quizás $ HOME / go / ... podría sustituirse en su lugar (o el equivalente en
Windows)?

Como ha agregado $ HOME / go / bin a su PATH (o $ GOPATH / bin si GOPATH es
colocar)...

Quizás en algún momento la documentación podría esperar que las personas no
solo establezca la variable de entorno PATH, pero también establezca GOPATH en $ HOME / go.
Aunque es redundante, aclara la documentación posterior.

La documentación inicial podría asumir el entorno predeterminado y no mencionar
variables en absoluto?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

La documentación inicial podría asumir las variables de entorno predeterminadas y no mencionar en absoluto.

SGTM

Hay dos tipos de usuarios de Go:

• Usuarios que simplemente obtienen paquetes existentes
• Usuarios que son desarrolladores de Go

GOPATH predeterminado está arreglando el caso para el primer grupo. Todavía podemos mantener las instrucciones relacionadas con GOPATH para los documentos orientados a los desarrolladores. La instalación ya no debería tener que mencionar la configuración de GOPATH o podemos tener un apéndice como lo menciona

Como alguien que tuvo que cambiar el nombre de ~ / bin / go debido a Go, me gusta sugerir que sea cual sea el valor predeterminado, si ya existe, debe tener un archivo .dot para indicar que realmente es de Go ~ / go. Cuando ~ / go no existe, go puede crearlo, crear el archivo .dot y las ejecuciones futuras pueden encontrarlo. Si establezco explícitamente GOPATH en ~ / go, entonces no será necesario ningún archivo .dot ya que no se está utilizando ningún valor predeterminado.

El archivo de puntos existe. Es el directorio src / dentro de $ HOME / go.

El miércoles 26 de octubre de 2016 a las 07:59, RalphCorderoy [email protected] escribió:

Como alguien que tuvo que cambiar el nombre de ~ / bin / go debido a Go, me gusta sugerir
que cualquiera que sea el valor predeterminado, si ya existe, entonces tiene que tener un
.dotfile en él para indicar que realmente es Go's ~ / go. Cuando ~ / go no existe,
go puede crearlo, hacer el archivo .dot y futuras ejecuciones pueden encontrarlo. Si yo
establezca explícitamente GOPATH en ~ / go, entonces no será necesario .dotfile ya que no
se está utilizando el valor predeterminado.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -256173981, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

CL https://golang.org/cl/32019 menciona este problema.

Incluso si algunos programadores no son conscientes de las variables de entorno,
debe al menos estar familiarizado con _variables_. Creo que vamos a necesitar
usar algo para describir la ubicación de un espacio de trabajo en los documentos, y
la cadena $GOPATH podría serlo.

El 26 de octubre de 2016 a las 06:24, Jaana Burcu Dogan [email protected]
escribió:

La documentación inicial podría asumir el entorno predeterminado y no mencionar
variables en absoluto.

SGTM

Hay dos tipos de usuarios de Go:

• Usuarios que simplemente obtienen paquetes existentes
• Usuarios que son desarrolladores de Go

GOPATH predeterminado está arreglando el caso para el primer grupo. Todavía podemos mantener
Instrucciones relacionadas con GOPATH para los documentos orientados a desarrolladores. los
la instalación ya no debería tener que mencionar la configuración de GOPATH o nosotros
puede tener un apéndice como @davecheney https://github.com/davecheney
menciones.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -256149104, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

Gracias es la intención, por favor vea la propuesta original.

En efecto, ahora podemos decir "Go get descargará la fuente a una carpeta
llamado, vaya / src / github.com / Foo / Bar dentro de su directorio de inicio "

El miércoles 26 de octubre de 2016, 06:01 Nathan Youngman [email protected] escribió:

Quizás $ HOME / go / ... podría sustituirse en su lugar (o el equivalente en
Windows)?

Como ha agregado $ HOME / go / bin a su PATH (o $ GOPATH / bin si GOPATH es
colocar)...

Quizás en algún momento la documentación podría esperar que las personas no
solo establezca la variable de entorno PATH, pero también establezca GOPATH en $ HOME / go.
Aunque es redundante, aclara la documentación posterior.

La documentación inicial podría asumir el entorno predeterminado y no mencionar
variables en absoluto?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

Este sería un gran problema para la última semana de Hacktoberfest.

El archivo de puntos existe. Es el directorio src / dentro de $ HOME / go

"src" es demasiado común para ser un "esto fue creado como un GOPATH by Go predeterminado" dotfile.

¿Qué es lo que está tratando de prevenir?

El miércoles 26 de octubre de 2016 a las 9:20 a. M., RalphCorderoy [email protected]
escribió:

El archivo de puntos existe. Es el directorio src / dentro de $ HOME / go

"src" es demasiado común para ser un "esto fue creado como predeterminado GOPATH por
Vaya a "dotfile.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -256194536, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$ HOME / ya estará.

¿Qué será para los usuarios de Windows?

Alex

Los usuarios de Windows usarán %USERPROFILE%\go , al igual que Docker aquí .

@davecheney , estoy tratando de evitar lo que dije hace dos horas: https://github.com/golang/go/issues/17262#issuecomment -256173981

Ir es una palabra común. Tenía un ~ / bin / go. La gente juega Go y tiene un código fuente que ver con jugar Go. Nabbing ~ / go por defecto cuando ya existe solo porque contiene src es de mala educación. Si ~ / go no existe, entonces Go puede tomar el nombre, crear el directorio, sellarlo como golang con un archivo de puntos significativo, por ejemplo, basado en el nombre de dominio golang.org.

Ese es el problema y, de todos modos, una posible solución. Incluso si la solución no es la correcta, eso no significa que el problema no exista.

Yo voto $ HOME / group

Gracias.

¿Podemos usar GOPATH por defecto como ~/.gosrc ?

¿Podemos usar GOPATH por defecto como ~/.gosrc ?

Esto estará oculto de forma predeterminada en Linux y OS X, y será visible en Windows. ¿Cuál sería la motivación para esconder a GOPATH?

La discusión sobre el valor del default tuvo lugar hace un mes. La decisión sobre $HOME/go ha tomado y ya se está implementando. Volver a ese tema solo hará que el hilo sea insoportablemente largo.

La gente juega Go y tiene un código fuente que ver con jugar Go.

Realmente no te estoy siguiendo, pero dado que habrás configurado GOPATH en
algo más ya, no habrá ningún impacto para ti.

El miércoles 26 de octubre de 2016 a las 9:43 a.m., RalphCorderoy [email protected]
escribió:

@davecheney https://github.com/davecheney , estoy tratando de evitar lo que
dijo hace dos horas: # 17262 (comentario)
https://github.com/golang/go/issues/17262#issuecomment -256173981

Ir es una palabra común. Tenía un ~ / bin / go. La gente juega Go y tiene código fuente
que ver con jugar go. Nabbing ~ / go por defecto cuando ya existe solo
porque contiene src es de mala educación. Si ~ / go no existe entonces Go
puede tomar el nombre, crear el directorio, sellarlo como golang con un
archivo de puntos significativo, por ejemplo, basado en el nombre de dominio golang.org.

Ese es el problema y, de todos modos, una posible solución. Incluso si la solucion
no es el correcto, eso no significa que el problema no exista.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -256199766, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

Hola @davecheney : Este problema comenzó con tu propuesta de ~ / gocode. Con el tiempo, se convirtió en ~ / go. @robpike dijo arriba "solo puede ser un problema elegir ese nombre si $ HOME / go ya existe, lo cual solo será feliz para los expertos que ya tienen go instalado y entenderán GOPATH". Creo que al estar envuelto en golang durante tanto tiempo, colectivamente se está olvidando lo común que es la palabra "ir" y cómo tiene otros significados, como el juego de mesa.

Este cambio está dirigido a los recién llegados a Go y algunos de ellos podrían tener ~ / go ya para un uso no Go. Estoy sugiriendo que si aparece go, encuentra que GOPATH no está configurado y no existe ~ / go, entonces puede crearlo, tomando el nombre. Pero si ~ / go existe, solo debería usarlo si puede decir que lo creó en una invocación anterior sin GOPATH. Sugerí que se creara un archivo de puntos como esta bandera. Dijiste que ~ / go / src servirá como esa bandera. Mi objeción es que src en sí mismo no es infrecuente entre los programadores, es decir, aquellos que podrían instalar Go. Un archivo de puntos inusual, por ejemplo, ~ / go / .default-gopath evita este posible conflicto.

Si crearon manualmente ~ / go para Go y ejecutan go sin GOPATH, entonces no usarán ~ / go porque falta el archivo dot. Creo que esto está bien, ya que al comenzar a configurar una instalación de Go, deberían continuar, configurando GOPATH. No son el simple caso de "instalar paquete, ejecutar go (1)" al que se apunta.

Si nada de esto se considera un problema, está bien. Pero mientras te quejes de que no entiendes mi punto, estoy condenado a seguir intentando explicarlo.

Es por eso que originalmente sugerí un camino diferente, con la sugerencia de Rob, ahora está oficialmente fuera de mis manos.

Dicho esto, estoy feliz de que se haya elegido _un_ camino, ya que lo veo como el objetivo del ejercicio.

Atendiendo a sus inquietudes, le recomiendo que siga https://go-review.googlesource.com/#/c/32019/ donde precisamente se está discutiendo el tema que le preocupa.

@RalphCorderoy , ¿le preocupa que los programadores de juegos de mesa tengan un directorio ~ / go para piratear juegos de mesa?

Rob y Russ son muy anti-dotfiles. Es mejor plantear el problema que dar la respuesta si la respuesta involucra archivos dot (o enlaces simbólicos).

@bradfitz , sí, ~ / go ya existe para los jugadores de gogame, y además ~ / go / src existe porque son jugadores programadores de gogame, de lo contrario no estarían jugando con Go. (Tengo ~ / chess / src como sucede).

La lógica de resumen de adg https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c parece estar bien, y estoy a favor de crear ~ / go si no existe, pero test -d ~/go/src es una prueba inestable para usar ~ / go si no hay GOPATH.

Si no fuera ~ / go, sino algo más inusual, como la sugerencia original de Dave, entonces no importaría. Creo que las encuestas de lo que se usa actualmente que mostró que ~ / go era muy popular no son demasiado útiles cuando los votantes son programadores de Go lo suficientemente interesados ​​como para seguir los problemas y las redes sociales.

@RalphCorderoy Creo que la cantidad de cuidado y calzoncillos dobles que se están diseñando en CL 32019 es más que suficiente para los posibles inconvenientes para el pequeño grupo de programadores que no han usado Go antes de la versión 1.8 y no han configurado GOPATH _y_ también están comenzando a aprender Go, el idioma.

La herramienta go no eliminará ni corromperá ningún código non go que encuentre, solo obtendrá un mensaje un poco confuso en unas pocas situaciones. Para explicar esto, la herramienta go no construirá la fuente Go en la parte superior de $GOPATH/src porque ese código no está dentro de un paquete importable. Además, el otro objetivo de este cambio es facilitar go get algunos códigos al proporcionar una ubicación predeterminada para descargar la fuente, por lo que _si_ existía el código fuente del juego-de-go en ~/go/src , las posibilidades de que entre en conflicto con un subdirectorio derivado de un repositorio go gettable son muy remotas, e incluso si eso sucediera, la herramienta go o git se estropearían antes de que se modificaran los datos.

Creo que la situación que le preocupa es muy poco probable y se mitiga aún más con la explicación anterior.

(Solo un argumento probablemente válido en contra de GOPATH=$HOME ): ¿Se aborda el rendimiento de goimports ? Recuerdo algo sobre un archivo .goimport_ignore . De lo contrario, el rendimiento de los editores populares podría verse afectado.

Por lo tanto, GOPATH!=$HOME es probablemente una opción libre de colisiones / no contaminada y debería ser eficaz.

@davecheney Después de go get tendría que limpiar una mierda de ~ / go / {bin, src, pkg} y no sería una buena introducción a Go después de haber pegado la línea que encontré en Internet.

@RalphCorderoy, por favor, comprenda que el objetivo de este cambio es facilitar las cosas a los nuevos usuarios de Go, no es usted, ya tiene $ GOPATH configurado, porque _tiene que_ con todas las versiones de Go desde la 1.1 en adelante. La superposición entre los usuarios del juego y los usuarios potenciales del lenguaje de programación es muy pequeña. No creo que haya ningún problema.

@RalphCorderoy La situación que estás describiendo es rara, y cualquiera que ejecute comandos de shell desde un sitio web aleatorio no debería tener expectativas de que sus discos no se borren, y mucho menos algunos archivos descargados y barajados en un directorio del mismo nombre. (Editar: considere la posibilidad de que Wine cree automáticamente y modifique .wine en el directorio de inicio del usuario. ¿Qué pasa si el usuario tiene algo más allí? Después de todo, "vino" es un término que usamos para una bebida en particular).

La colisión de nombres entre "Go", el idioma y "Go", el juego de mesa, es sin duda entendida y bien conocida. El sistema de archivos es un recurso compartido, las colisiones ocurren y son inevitables.

@davecheney , deje de decirme que este cambio no tiene como objetivo ayudarme porque no soy un usuario nuevo de Go. Siempre he sido consciente de eso incluso antes de que empezaras a señalarlo. También entiendo que su posición es len (intersect (existente- ~ / go, GOPATH-less)) es demasiado pequeña para ser motivo de preocupación.

Después de haber limpiado el go-get spew en ~ / go porque sabría lo que normalmente no estaba allí, tendría que investigar para ver qué más pueden haber hecho los comandos en $ HOME en caso de que haya más se requirió limpieza.

darse de baja

Lo siento si te he ofendido. Ya no deseo corresponder
contigo en este tema. Gracias.

El viernes 28 de octubre de 2016 a las 3:28 a.m., RalphCorderoy [email protected]
escribió:

@davecheney https://github.com/davecheney , por favor deje de decirme esto
el cambio no tiene como objetivo ayudarme porque no soy un usuario nuevo de Go. yo tengo
Siempre he sido consciente de eso incluso antes de empezar a señalarlo. Yo también
entender que su posición es len (intersectar (existente- ~ / ir, GOPATH-menos)) es
demasiado pequeño para ser motivo de preocupación.

Después de haber limpiado el go-get spew in ~ / go porque sabría qué
normalmente no estaba allí, entonces tendría que investigar para ver qué más
Los comandos pueden haberse realizado en $ HOME en caso de que se requiriera más limpieza.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/17262#issuecomment -256697043, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

Davecheney: No, no te ofendas. Simplemente no tiene sentido seguir cubriendo el mismo terreno.

Me pregunto: ¿cuál es el comportamiento esperado si $HOME no está configurado?

Si bien nunca he trabajado en un sistema en el que ese fuera el caso, parece posible que alguien haya modificado sus variables de entorno predeterminadas por alguna razón, y este caso de borde debe manejarse de manera consistente.

Creo que actualmente evalúa $GOPATH='' ; ¿Eso significa que va a usar el directorio de trabajo actual?

usar el directorio de trabajo actual

Se me ocurrió que esto podría ser lo más útil para un nuevo usuario de Go que no ha configurado GOPATH. Un go get sería similar a un wget, etc., llenando el directorio actual. No están interesados ​​en el aspecto de la ruta de GOPATH en este momento, y es muy posible que quieran que cada una de sus aventuras en jugar con diferentes cosas en línea sea distinta, como les daría un nuevo directorio temporal de su propia creación. Pueden obtener, ejecutar y eliminar fácilmente los diferentes repositorios que ven referenciados.

• si GOPATH no se establece:
  
  
  
  • si solo uno o dos, pero no todos, de ~ / {bin, pkg, src} existen:
  
  
  • tienen que configurar GOPATH, pkg es el inusual
  
  
  • de lo contrario, existen todos o ninguno:
  
  
  • asegúrese de que todos existan
  
  
  • GOPATH = $ (pwd)
  
  

Tengo sentimientos encontrados sobre esto, pero mi opinión predominante (como alguien que ha establecido $GOPATH ) es que el comportamiento de go get debe ser "determinista" y siempre instalar cosas debajo de $GOPATH - un destino coherente y bien documentado.

Aunque este cambio no me afecta, me parece extraño que go get descargue cosas en diferentes ubicaciones dependiendo de cuál sea el directorio de trabajo cuando se emite el comando. Soy consciente de que esto es lo que hacen wget , npm install y otras herramientas, pero parece una desviación de la idea de un $GOPATH constante de

Si esto está más allá del alcance de este problema, propondría simplemente salir y generar un error si $HOME realidad no está configurado.

He enseñado a 5 nuevos programadores que vinieron del mundo Java en un país del tercer mundo. Todos estaban confundidos con seguridad acerca de GOPATH. Diablos, yo también lo estaba cuando empecé antes de que se lanzara Go 1. Yo personalmente uso "$ HOME / gopath" pero sugiero que el comando "go get" los dirija a un blog go que es CLARO sobre cómo crear una ruta go para su sistema operativo. Eso es todo lo que necesitamos. Alguna guía por el comando "go get" que no es una especificación .. ¡¡Pero una publicación de blog malditamente simple !!

Obviamente me refiero a cuando no se ha establecido GOPATH. Simplemente actualice el mensaje de error que se muestra actualmente. La tasa de adopción ya está ahí ... Solo necesito un poco de ayuda en lugar del método actual de google it up que están haciendo los recién llegados.

@einthusan Siento que está bastante bien documentado en https://golang.org/doc/code.html#GOPATH , pero no sé cuántas personas que comienzan con Go realmente leen esta página.

Perdón por enviar spam ... Después de buscar en Google ... Creo que "go get" debería indicarle al usuario que dice "No se ha establecido ningún GOPATH ... ¿Le gustaría usar el directorio de trabajo actual como su GOPATH temporal?" (Sí No)

@einthusan , no hay precedente para cmd / go haciendo indicaciones interactivas.

Si el nuevo GOPATH predeterminado es $ HOME / go. ¿No esperaría la gente que este https://hub.docker.com/_/golang/ adoptara el mismo comportamiento?

@cescoferraro esa es una pregunta para los mantenedores de esa imagen. A pesar de estar etiquetado como "oficial", ese proyecto no está afiliado a Go.

Responder / responder a mi propia pregunta sobre el desarmado $HOME :

En la implementación actual (el CL está vinculado arriba), $GOPATH defecto es "" si $HOME está configurado: https://go-review.googlesource.com/#/ c / 32019/11 / src / go / build / build.go Creo que esto es consistente con el comportamiento actual.

Creo que este caso de borde es muy poco probable, ya que $HOME siempre se configura en una sesión de inicio de sesión normal, que es probablemente el caso de la mayoría de los programadores de Go. Aunque personalmente me gustaría que el comportamiento se aclarara explícitamente, parece que no hay "efectos secundarios" (como instalar cosas en el directorio de trabajo). Corrígeme si estoy equivocado. :)

Si esto se hace más fácil para las personas que comienzan con Go por primera vez, deje que sea algo como la ruta actual:

GOPATH=$(pwd)

Establecer export GOPATH=$(pwd) facilita el cambio entre proyectos

Mi comportamiento propuesto para este cambio:

Variables de entorno

• Si se establece GOPATH , las herramientas se comportan como siempre
• De lo contrario, verificamos la variable de entorno HOME ( home para plan9, USERPROFILE para windows).
  
  
  
  • Si esa variable env no está configurada, GOPATH tampoco se configurará: esto significa que "go get" fallará con cannot download, $GOPATH not set.
  
  

> unset GOPATH
> unset HOME
> go env GOPATH

• De lo contrario, GOPATH se establecerá como $HOME/go ( $home/go , %USERPROFILE%\go ).

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

Creación de GOPATH

Actualmente, si $GOPATH no existe, se crea cuando ejecutamos go get import/path . Esto no cambiará.

El único cambio es que si $GOPATH no está configurado en el entorno del usuario (es decir, echo $ GOPATH no muestra ningún valor) se realiza una verificación adicional para asegurarse de que el valor predeterminado sea aceptable:

• si GOPATH no está configurado y no se creó un valor predeterminado: el comando fallará

> 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 el valor predeterminado $GOPATH no existe, se mostrará una advertencia explicando que el directorio fue creado, apuntando a go help gopath para obtener más información.

> 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 existe el $GOPATH predeterminado:
  
  
  
  • y no es un directorio: el comando fallará (como lo hizo antes)
  
  

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

• y es un directorio vacío o un directorio que tiene un subdirectorio llamado src el comando tendrá éxito (sin advertencias)

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

• y es un directorio no vacío sin un subdirectorio llamado src el comando fallará

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

Por lo tanto, solo se incluye una nueva advertencia cada vez que se crea un directorio con un GOPATH predeterminado.

@campoy la propuesta de comportamiento se ve muy bien.

Pero nuevamente, como usuario avanzado, quiero saber cuántos de nosotros usamos seriamente $HOME/go como GOPATH a diario. Incluso estaba pensando que tal vez debería haber un comando go para configurar GOPATH similar a iniciar un entorno virtual en un directorio de trabajo de Python.

Como trabajo en varios proyectos, suelo hacer algo como esto:

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

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

@jinmatt
Este cambio solo modifica el comportamiento de GOPATH desarmado, ese es el alcance del cambio.
La comunidad ya llegó a un acuerdo sobre $ HOME / go.

Si no le gusta $HOME/go , simplemente establezca GOPATH en el valor que prefiera (por ejemplo, $ HOME en mi caso).

Gracias por el boceto de diseño.

1. Dado que ahora hemos establecido que GOPATH solo se creará durante 'go get', solo imprimamos mensajes si se da la bandera -v, de acuerdo con el resto del comportamiento de 'go get -v'.
2. Si se crea el directorio, el mensaje debe ser como máximo

# creado GOPATH = / users / campoy / go; ver 'ir a ayudar a gopath'

No es una advertencia: las advertencias son malas. Por otro lado, si la creación falla, es posible que desee imprimir

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

Ambos mensajes se pueden imprimir independientemente de si GOPATH se infiere o se establece explícitamente.

1. Las heurísticas sobre un directorio vacío y tener un subdirectorio src son demasiado complejas. Peor aún, están abordando problemas hipotéticos y los hipotéticos son muy difíciles de diseñar. Es mejor tener un comportamiento más simple y predecible. Para empezar, creo que tiene sentido no tener reglas hasta que haya ejemplos concretos de problemas reales. Habrá tiempo para que las personas informen sobre problemas durante las betas y publiquen candidatos. Establezcamos GOPATH = $ HOME / go (siempre que se establezca $ HOME).

Editar: pretenda que la rebaja de Github no arruinó completamente esto.

@campoy Con respecto al directorio src/ , ¿cuál es el comportamiento actual de go get cuando se establece un GOPATH pero no existe un directorio src? ¿Existe una buena razón para no crearlo también?

Parece más sencillo explicar si $ HOME / go / src se crea en el primer go get (o $ GOPATH / src si esa variable de entorno está configurada)

Hoy, cuando se configura GOPATH, se crean los directorios necesarios, incondicionalmente, según sea necesario.

CL https://golang.org/cl/33356 menciona este problema.

CL https://golang.org/cl/33730 menciona este problema.