gopkg - go dep

¿Cómo debo usar el proveedor en Go 1.6? (1)

Primero he leído esta respuesta: Vendoring en Go 1.6 , luego la uso como mi ejemplo.

Mi gopath es GOPATH="/Users/thinkerou/xyz/" , y el siguiente me gusta:

thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ pwd /Users/baidu/xyz/src/ou thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ ls main.go vendor

Ahora, uso go get , luego se convierte en esto:

thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ ls main.go vendor thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ cd vendor/ thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ ls vendor.json thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ cd ../.. thinkerou@MacBook-Pro-thinkerou:~/xyz/src$ ls github.com ou thinkerou@MacBook-Pro-thinkerou:~/xyz/src$ cd github.com/ thinkerou@MacBook-Pro-thinkerou:~/xyz/src/github.com$ ls zenazn

vendor.json es este:

{ "comment": "", "package": [ { "path": "github.com/zenazn/goji" } ] }

entonces, debo usar que comandos? ¿Por qué no tener un vendor uso? Mi versión go es 1.6.2.

Con Go1.6, el vendedor está integrado a medida que lee. ¿Qué significa esto? Solo una cosa a tener en cuenta:

Cuando se usan las herramientas de go , como go build o go run , primero verifican si las dependencias se encuentran en ./vendor/ . Si es así, úsalo. Si no, vuelva al $GOPATH/src/ .

Las "rutas de búsqueda" reales en Go 1.6 son, en orden:

./vendor/github.com/zenazn/goji $GOPATH/src/github.com/zenazn/goji $GOROOT/src/github.com/zenazn/goji

Dicho esto, go get continuará instalando en ti $GOPATH/src ; y, go install se instalará en $GOPATH/bin para binarios o $GOPATH/pkg para el almacenamiento en caché de paquetes.

Entonces, ¿cómo uso ./vendor?!?!

Jeje, armado con el conocimiento de arriba, es bastante simple:

mkdir -p $GOPATH/src/ou/vendor/github.com/zenazn/goji cp -r $GOPATH/src/github.com/zenazn/goji/ $GOPATH/src/ou/vendor/github.com/zenazn/goji

En resumen, para utilizar el proveedor, copie los archivos utilizando la misma github.com/zenazn/goji completa github.com/zenazn/goji , en el director de su proveedor.

Ahora, las herramientas de construir / instalar / ejecutar verán y usarán su carpeta de proveedor.

Una forma más fácil en lugar de copiar todo manualmente.

En lugar de buscar y copiar los más de 25 artículos de proveedores, administrar sus versiones, actualizar otros proyectos, etc. Sería mejor usar una herramienta de administración de dependencias . Hay muchos por ahí y un poco de Google te señalará varios.

Permítanme mencionar dos que funcionan con la carpeta del proveedor y no pelean contra usted:

Godep
gobernador

En resumen, estas herramientas inspeccionarán su código ou , encontrarán las dependencias remotas y las copiarán desde su $GOPATH/src a su $GOPATH/src/ou/vendor (en realidad, cualquiera que sea el directorio actual en el que se encuentre cuando las ejecute) .

Por ejemplo, supongamos que tiene todas sus dependencias instaladas y trabajando normalmente en su $GOPATH/src/ou/ project utilizando la instalación normal de GOPATH / src / github de sus dependencias. Su proyecto se ejecuta y sus pruebas validan que todo funciona con la versión exacta de los repositorios que tiene. Con Godep como ejemplo, ejecutaría esto desde la carpeta raíz de su proyecto $GOPATH/src/ou/ :

godep save ./...

Esto copiaría todas las dependencias que usa su proyecto en su carpeta ./vendor.

Godep es por mucho y el más popular. Tienen su propio canal Slack en el grupo Gopher Slack. Y, es el que uso en mis equipos.

Govendor es otra alternativa que leí que tiene una buena función de sincronización. Aunque no lo he usado.

Sobre uso de herramienta de gestión de dependencia

Esto es puramente una opinión, y estoy seguro de que los enemigos rechazarán ... Pero como tengo que terminar mi publicación del blog sobre el tema, permítanme mencionar aquí que la mayoría de las personas se preocupan demasiado por la gestión de la dependencia en Go.

Sí, es necesario bloquear un repositorio de una versión de la que dependa para que pueda asegurarse de que su sistema se construye en producción. Sí, es necesario asegurarse de que no haya cambios de ruptura en la forma en que una dependencia está interrumpiendo algo.

Utilice la gestión de dependencia para aquellos, absolutamente.

Pero, hay un uso excesivo de proyectos simples que bloquean grandes cantidades de dependencias cuando en realidad ...

Es posible que solo necesite bloquear 1 dependencias; de lo contrario, querrá la última versión de los controladores MySQL y los marcos de prueba de prueba para la corrección de errores.

Aquí es donde puede brillar el uso de la carpeta ./vendor/ aparte de las herramientas de administración de dependencias: solo necesita copiar el repositorio que necesita para bloquearlo.

Seleccionas selectivamente el repo de mal comportamiento y lo pones en tu carpeta ./vendor/. Al hacer esto, le está diciendo a sus consumidores:

Hey, este repo debe ser retenido en esta revisión. Todos los demás están bien y usan lo último de ellos y se actualizan a menudo con go get -u ./... ; pero, este falló con las versiones más nuevas, así que no actualice este repositorio.

Pero si guarda todas sus dependencias con una herramienta de administración de dependencias, básicamente le está diciendo a sus consumidores:

Puede o no haber un problema con uno o más repositorios de los 20 en la carpeta del proveedor. Puede o no puede actualizarlos. Puede o no puede obtener el último controlador MySQL. Simplemente no sabemos qué puede estar causando problemas o no, y simplemente estamos bloqueados en algo que funcionó en el momento en que corrí godep save . Así que sí, actualizar bajo su propio riesgo.

Personalmente, me he topado con esto varias veces. Se actualizó una dependencia con un cambio de ruptura, y tenemos docenas de repos que dependen de ella. La venta de solo un repositorio en / proveedor nos permite usar esa versión de dependencia, mientras que go get ./... continúa ejecutándose normalmente en todos los demás repositorios para obtener la última. Corremos con las últimas correcciones de errores en PSQL y MySQL y otros (¡hay correcciones constantes para estos!) Y así sucesivamente.