go installes parte del flujo de trabajo cuando se trabaja localmente. Supongamos que desea utilizar una biblioteca, pero por alguna razón se requiere un cambio. Tu harías:
go get -d library, que solo lo descarga;go install library para instalar la versión local.Hasta donde yo sé, go getno tiene indicadores que indiquen que no debería descargarse, por lo que no puede reemplazar go installaquí.
Se utiliza el mismo flujo de trabajo cuando se desarrolla un nuevo paquete desde cero.
go get hace dos cosas principales en este orden:
descarga y guarda en $GOPATH/src/<import-path>los paquetes (código fuente) nombrados en las rutas de importación, junto con sus dependencias, luego
ejecuta un go install
La -dbandera ( go get -d) indica go getque se detenga después de descargar los paquetes; es decir, instruye a go getno hacergo install
la diferencia:
go get // verificar si los paquetes necesitan ser descargados, descargarlos si es necesario y luego compilarlos
go install // omita la parte con la descarga de paquetes, solo compile (esto arrojará un error si falta algún paquete)
sobre GOPATHla variable de entorno
Las GOPATHherramientas de Go utilizan la variable de entorno. Se debe establecer con el fin de ser capaz de get, buildyinstall paquetes, y especifica la ubicación de su espacio de trabajo. Es probable que sea la única variable de entorno que necesitará establecer al desarrollar código Go.
De nuevo, el GOPATH no debe apuntar a la instalación de Go, sino a su espacio de trabajo.
Por ejemplo, en Windows, si decide que su espacio de trabajo está en c:\gowork\, deberá establecer el GOPATHvalor comoc:\gowork
Su código fuente debe estar en c:\gowork\src\<some project folder>\y después de ejecutarlo go geten el símbolo del sistema desde dentro c:\gowork\src\<some project folder>\, verá c:\gowork\bin\y se c:\gowork\pkg\está creando.
go installdescarga el paquete en una configuración compatible con módulos.
Tenga en cuenta que la versión 1.16 (Q1 2021) hará que esa diferencia sea más clara, implementada con CL 266360 como parte del problema 40276 :
go installahora acepta argumentos con sufijos de versión (por ejemplo,go install example.com/cmd@v1.0.0).
Esto hacego installque se compilen e instalen paquetes en modo de reconocimiento de módulos , ignorando elgo.modarchivo en el directorio actual o cualquier directorio principal, si lo hay.
Esto es útil para instalar ejecutables sin afectar las dependencias del módulo principal .
go install, con o sin un sufijo de versión (como se describe arriba), es ahora la forma recomendada de construir e instalar paquetes en modo módulo.
go getdebe usarse con la-dbandera para ajustar las dependencias del módulo actual sin compilar paquetes, y el uso dego getpara compilar e instalar paquetes está en desuso .
En una versión futura, la-dbandera siempre estará habilitada .
go get ./path/to/local_package, y se comportaría igual que si lo usarago install ./path/to/local_package, ¿verdad? Dado que no hay proceso de descarga en este caso.go installhace que su objetivo sea más explícito, pero supongo que ambos lograrían lo mismo. Probé con algunos paquetes, incluidos los declarados comomainy parecían equivalentes. Los documentos son muy deficientes en este comando.go getpero no parago install. ¿Cómo se relaciona eso con esta descripción?go getlugar dego installen su tercer punto, yago getque no volverá a descargar la biblioteca (a menos que agregue-u). También puede utilizarlogo getal escribir una biblioteca desde cero.go installparece completamente redundante.