management gopkg golang ensure dependency dep go

gopkg - Mejores prácticas de gestión de dependencias de Golang



go dep (4)

En Golang, podemos especificar bibliotecas de código abierto en GitHub como dependencias. Por ejemplo:

import "github.com/RichardKnop/somelibrary"

Esto intentará buscar una rama basada en su versión Go y predeterminada para masterizar si entiendo correctamente.

Por lo tanto, no hay forma de importar una versión específica de una dependencia, por ejemplo:

import "github.com/RichardKnop/somelibrary#v1.4.8"

¿Cuál es la mejor práctica para administrar dependencias en Go entonces?

Puedo ver dos enfoques.

I. Módulos de versión

¿Es para crear nuevos módulos para versiones principales con cambios importantes?

Por ejemplo, mi biblioteca Go podría definir los módulos v1 y v2 para que pueda hacer lo siguiente:

import "github.com/RichardKnop/somelibrary/v1"

O:

import "github.com/RichardKnop/somelibrary/v2"

De acuerdo con lo que necesitas. Se requeriría que cualquier cambio realizado en v1 o v2 no rompa ninguna API o funcionalidad de trabajo.

II Bifurcación

Esto le daría un control completo sobre una versión de dependencia externa que requiere su código Go.

Por ejemplo, puede bifurcar github.com/RichardKnop/somelibrary en su propia cuenta de GitHub y luego en su código hacer:

import "github.com/ForkingUser/somelibrary"

Entonces tendrías que bifurcar todas las dependencias externas, lo que parece un poco exagerado. Sin embargo, le daría un control total sobre las versiones. Puede mantener sus horquillas en una versión que sabe que funciona con su código y solo actualizar las horquillas una vez que haya verificado que las nuevas versiones de dependencias no rompen nada.

Pensamientos?

Actualización de agosto de 2018: esto (vgo presentado a continuación) ahora se implementa con Go 1.11 y módulos .

Actualización de febrero de 2018, 3 años después.

Existe un nuevo enfoque desarrollado por Russ Cox , del equipo central de desarrollo de Golang.

El proyecto vgo .

go get -u golang.org/x/vgo

Esta propuesta:

  • mantiene las mejores partes de go get ,
  • agrega compilaciones reproducibles ,
  • adopta versiones semánticas,
  • elimina la venta ,
  • desprecia a GOPATH a favor de un flujo de trabajo basado en proyectos, y
  • proporciona una ruta de migración sin problemas desde dep y sus predecesores.

Se basa en un nuevo algoritmo MVS ("Selección de versión mínima") :

Puedes ver:

Mayo de 2018: Artifactory propone un proxy vgo

El lanzamiento reciente de Artifactory 5.11 agregó soporte para registros Go compatibles con vgo (y go proxy), lo que brinda a la comunidad una variedad de capacidades al desarrollar con Go.
Estos son solo algunos de ellos:

  • Los repositorios locales en Artifactory le permiten configurar registros Go privados y seguros con un control de acceso específico a paquetes de acuerdo con proyectos o equipos de desarrollo.
  • Un repositorio remoto en Artifactory es un proxy de almacenamiento en caché para recursos Go remotos, como un proyecto GitHub. El acceso a un proxy de Go a través de Artifactory elimina su dependencia de la red o de GitHub, ya que todas las dependencias necesarias para sus compilaciones de Go se almacenan en caché en Artifactory y, por lo tanto, están disponibles localmente. Esto también elimina el riesgo de que alguien mute o elimine una dependencia del control de versiones, o peor aún, forzar cambios a una etiqueta Git remota, cambiando así lo que debería ser una versión inmutable que puede crear mucha confusión e inestabilidad para proyectos dependientes.
  • Un repositorio virtual agrega registros Go locales y remotos que le dan acceso a todos los recursos Go necesarios para sus compilaciones desde una sola URL, ocultando la complejidad de usar una combinación de recursos locales y remotos.

Febrero de 2018: el enfoque de venta presentado a continuación (en 2015/2016) podría terminar desapareciendo si vgo se integra a la cadena de herramientas.
Mira mi respuesta a continuación .

Edición de agosto de 2015: Go 1.5 viene con un soporte de venta incorporado (pero aún experimental). La configuración de la variable de entorno GO15VENDOREXPERIMENT hará que go build y sus amigos busquen paquetes en el directorio ./vendor y en GOPATH . Vea la respuesta de VonC y el documento de diseño para más detalles.

III. Vendiendo

AFAIK, esta es la forma más utilizada de garantizar que sus compilaciones sean reproducibles y predecibles. El equipo Go en sí usa la venta en su repositorio. El equipo de Go ahora está discutiendo el formato de archivo de manifiesto de dependencia unificado. De la lista de correo de desarrolladores de Go toolchain :

En el árbol fuente interno de Google, vendemos (copiamos) todas nuestras dependencias en nuestro árbol fuente y tenemos como máximo una copia de cualquier biblioteca externa dada. Tenemos el equivalente de un solo GOPATH y reescribimos nuestras importaciones para referirnos a nuestra copia vendida. Por ejemplo, el código Go dentro de Google que quiera usar "golang.org/x/crypto/openpgp" lo importaría como algo así como "google / third_party / golang.org / x / crypto / openpgp".

(...)

Nuestra propuesta es que el proyecto Go,

  • oficialmente recomienda vender en un directorio "interno" con reescritura de importación (no modificaciones de GOPATH) como la forma canónica de anclar dependencias.

  • define un formato de archivo de configuración común para dependencias y proveedores

  • no realiza cambios de código en cmd / go en Go 1.5. Las herramientas externas como " godep " o " nut " implementarán 1) y 2). Podemos reevaluar la inclusión de dicha herramienta en Go 1.6+.

Nota: ¡Junio ​​de 2015, el primer soporte para la venta aparece en Go 1.5!

Ver c/10923/ :

Cuando GO15VENDOREXPERIMENT=1 está en el entorno, este CL cambia la resolución de las rutas de importación de acuerdo con la propuesta del proveedor Go 1.5:

  • Si hay un directorio fuente d/vendor , cuando compila un archivo fuente dentro del subárbol enraizado en d , la import "p" se interpreta como import "d/vendor/p" si existe.
  • Cuando hay varias resoluciones posibles, gana la ruta más específica (más larga).
  • Siempre se debe usar la forma abreviada: ninguna ruta de importación puede contener " /vendor/ " explícitamente.
  • Los comentarios de importación se ignoran en los paquetes distribuidos.

Actualización de enero de 2016: Go 1.6 hará que la venta sea la predeterminada.
Y como se detalla en el artículo "LA MAYORÍA DE LAS HERRAMIENTAS IR A TRABAJAR CON GO15VENDOREXPERIMENT" :

1.6 brinda soporte para /vendor/ para la mayoría de las herramientas (como el oráculo) fuera de la caja; usa la Beta para reconstruirlos.

también es posible simplemente describir dependencias en maven, si usar mvn-golang-wrapper , en el caso que se vea en maven como se muestra a continuación

<plugin> <groupId>com.igormaznitsa</groupId> <artifactId>mvn-golang-wrapper</artifactId> <version>1.1.0</version> <executions> <execution> <id>golang-get</id> <goals> <goal>get</goal> </goals> <configuration> <packages> <package>github.com/gizak/termui</package> </packages> <buildFlags> <flag>-u</flag> </buildFlags> <goVersion>1.6</goVersion> </configuration> </execution> </plugin>