modules management govendor golang ensure enable dependency dep go package package-managers

management - ¿Cómo importo una versión específica de un paquete usando go get?



golang vendor (8)

viniendo de un entorno Node solía instalar una versión específica de una lib de proveedor en la carpeta del proyecto ( node_modules ) diciendo a npm que instale esa versión de lib desde el package.json o incluso directamente desde la consola, así:

$ npm install [email protected]

Luego solía importar esa versión de ese paquete en mi proyecto solo con:

var express = require(''express'');

Ahora, quiero hacer lo mismo con go . ¿Cómo puedo hacer eso? ¿Es posible instalar una versión específica de un paquete? Si es así, usando un $GOPATH centralizado, ¿cómo puedo importar una versión en lugar de otra?

Haría algo como esto:

$ go get github.com/wilk/[email protected] $ go get github.com/wilk/[email protected]

Pero entonces, ¿cómo puedo hacer una diferencia durante la importación?



El enfoque que he encontrado viable es el sistema de submódulos de git . Usando eso, puedes submódulo en una versión dada del código y la actualización / degradación es explícita y grabada, nunca al azar.

La estructura de carpetas que he tomado con esto es:

+ myproject ++ src +++ myproject +++ github.com ++++ submoduled_project of some kind.


Puede configurar la versión por depósito oficial

dep ensure --add github.com/gorilla/[email protected]


Puedes usar git checkout para obtener una versión específica y construir tu programa usando esta versión.

Ejemplo:

export GOPATH=~/ go get github.com/whateveruser/whateverrepo cd ~/src/github.com/whateveruser/whateverrepo git tag -l # supose tag v0.0.2 is correct version git checkout tags/v0.0.2 go run whateverpackage/main.go


Realmente sorprendido, nadie ha mencionado gopkg.in .

gopkg.in es un servicio que proporciona un contenedor (redirección) que le permite expresar versiones como URL de repositorio, sin crear repos. por ejemplo, gopkg.in/yaml.v1 vs gopkg.in/yaml.v2, aunque ambos viven en https://github.com/go-yaml/yaml

Esto no es perfecto si el autor no sigue las prácticas de control de versiones correctas (al aumentar el número de versión cuando se rompe la compatibilidad con versiones anteriores), pero sí funciona con ramas y etiquetas.


dep es el experimento oficial para la administración de dependencias para el lenguaje Go. Requiere Go 1.8 o posterior para compilar.

Para comenzar a administrar dependencias usando dep , ejecute el siguiente comando desde el directorio raíz de su proyecto:

dep init

Después de la ejecución, se generarán dos archivos: Gopkg.toml ("manifest"), Gopkg.lock y los paquetes necesarios se descargarán en el directorio del vendor .

Supongamos que tienes el proyecto que usa el paquete github.com/gorilla/websocket . dep generará los siguientes archivos:

Gopkg.toml

# Gopkg.toml example # # Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md # for detailed Gopkg.toml documentation. # # required = ["github.com/user/thing/cmd/thing"] # ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"] # # [[constraint]] # name = "github.com/user/project" # version = "1.0.0" # # [[constraint]] # name = "github.com/user/project2" # branch = "dev" # source = "github.com/myfork/project2" # # [[override]] # name = "github.com/x/y" # version = "2.4.0" [[constraint]] name = "github.com/gorilla/websocket" version = "1.2.0"

Gopkg.lock

# This file is autogenerated, do not edit; changes may be undone by the next ''dep ensure''. [[projects]] name = "github.com/gorilla/websocket" packages = ["."] revision = "ea4d1f681babbce9545c9c5f3d5194a789c89f5b" version = "v1.2.0" [solve-meta] analyzer-name = "dep" analyzer-version = 1 inputs-digest = "941e8dbe52e16e8a7dff4068b7ba53ae69a5748b29fbf2bcb5df3a063ac52261" solver-name = "gps-cdcl" solver-version = 1

Hay comandos que le ayudan a actualizar / eliminar / etc paquetes, por favor encuentre más información en dep of dep dep (herramienta de administración de dependencias para Go).


ve a buscar es el administrador de paquetes de Go. Funciona de una manera completamente descentralizada y cómo el descubrimiento de paquetes aún es posible sin un repositorio central de alojamiento de paquetes.

Además de localizar y descargar paquetes, la otra gran función de un administrador de paquetes es manejar múltiples versiones del mismo paquete. Go adopta el enfoque más mínimo y pragmático de cualquier administrador de paquetes. No hay tal cosa como múltiples versiones de un paquete Go.

go get siempre tira de HEAD de la rama predeterminada en el repositorio. Siempre. Esto tiene dos implicaciones importantes:

  1. Como autor del paquete, debe adherirse a la filosofía HEAD estable. Su sucursal predeterminada siempre debe ser la versión estable y lanzada de su paquete. Debe trabajar en ramas de características y solo fusionar cuando esté listo para lanzar.

  2. Las nuevas versiones principales de su paquete deben tener su propio repositorio. En pocas palabras, cada versión principal de su paquete (después de las versiones semánticas) tendría su propio repositorio y, por lo tanto, su propia ruta de importación.

    por ejemplo, github.com/jpoehls/gophermail-v1 y github.com/jpoehls/gophermail-v2.

Como alguien que construye una aplicación en Go, la filosofía anterior realmente no tiene un inconveniente. Cada ruta de importación es una API estable. No hay números de versión de qué preocuparse. ¡Increíble!

Para más detalles: http://zduck.com/2014/go-and-package-versioning/


Glide es una gestión de paquetes realmente elegante para Go, especialmente si vienes de Node''s npm o de la carga de Rust.

Se comporta de cerca con la nueva función de proveedor de Godep en 1.6 pero es mucho más fácil. Sus dependencias y versiones están "bloqueadas" dentro de su directorio de directorio de proyecto / proveedor sin depender de GOPATH.

Instalar con brew (OS X)

$ brew install glide

Inicie el archivo glide.yaml (similar a package.json). Esto también captura los paquetes importados existentes en su proyecto de GOPATH y luego los copia al proveedor / directorio del proyecto.

$ glide init

Obtenga nuevos paquetes

$ glide get vcs/namespace/package

Actualice y bloquee las versiones de los paquetes. Esto crea el archivo glide.lock en su directorio de proyecto para bloquear las versiones.

$ glide up

Intenté deslizarme y lo utilicé felizmente para mi proyecto actual.