¿Qué significa “incompatible” en go.mod, causará daño?

Después de consultar especialistas en esta materia, programadores de diversas ramas y profesores hemos dado con la solución a la interrogande y la plasmamos en esta publicación.

Solución:

La respuesta aceptada es correcta, pero realmente no es amigable para mí, que solo me pongo en contacto con el módulo go. Hice una investigación basada en la respuesta y una conclusión basada en esto como a continuación, en caso de que alguien necesitara:

Los comandos estándar como go build o go test agregarán automáticamente nuevas dependencias según sea necesario para satisfacer las importaciones (actualizando go.mod y descargando las nuevas dependencias). Pero hay varias situaciones diferentes que darán como resultado diferentes selecciones de versión:

1. Si un repositorio no ha optado por los módulos, pero se ha etiquetado con etiquetas semver válidas, mientras tanto, es un módulo v0 / v1, consulte esto:

   no participaron en módulos: significa no go.mod en el árbol de origen

   etiquetas semver válidas: significa que el repositorio usa la etiqueta git para etiquetarlo como algo como vX.Y.Z

   módulo v0 / v1: significa que el valor de la versión principal (es decir, X) es 0 o 1, por ejemplo, v0.1.0, v1.2.3

   Entonces, usará un pseudo-version, algo como github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181

2. Si un repositorio no ha optado por los módulos, pero ha sido etiquetado con etiquetas semver válidas, mientras tanto, es un módulo v2 +, vea esto:

   módulo v2 +: significa que el valor de la versión principal (es decir, X) es> = 2, p. ej. v4.1.0

   Entonces, se mostrará como incompatible, algo como github.com/zeromq/goczmq v4.1.0+incompatible

3. Si un repositorio ya ha optado por los módulos, pero no ha sido etiquetado con etiquetas semver válidas:

   Entonces, se comportará como 1, use pseudo-version.

4. Si un repositorio ya ha optado por los módulos y se ha etiquetado con etiquetas semver válidas, mientras tanto, es un módulo v0 / v1:

   Entonces, se comportará normalmente como github.com/stretchr/testify v1.3.0

5. Si un repositorio ya ha optado por los módulos y se ha etiquetado con etiquetas semver válidas, mientras tanto, es un módulo v2 +:

   Luego, al importar en código fuente, necesitamos agregar /vN al final, p. ej., import "github.com/my/mod/v4", y en go.mod se comportará como github.com/my/mod/v4 v4.1.0

+incompatible significa que la dependencia tiene una versión semver major de 2 o superior y aún no es un módulo Go (no tiene go.mod en su código fuente).

El nombre del módulo debería haber sido github.com/zeromq/goczmq/v4 en lugar de github.com/zeromq/goczmq para las versiones v4 y superiores (v4.1.0, v4.2.0, etc.).

Dado que github.com/zeromq/goczmq no ha adoptado los módulos Go correctamente, el go get fallará si se usa Go 1.13 y el GOPROXY está configurado para dirigir o para algún otro servidor que no aloje este archivo –

    go get github.com/zeromq/[email protected]+incompatible
    go: finding github.com v4.2.0+incompatible
    go: finding github.com/zeromq v4.2.0+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go get github.com/zeromq/[email protected]+incompatible: github.com/zeromq/[email protected]+incompatible: invalid version: +incompatible suffix not allowed: module contains a go.mod file, so semantic import versioning is required

Más detalles mencionados en el ‘Validación de versión‘aquí: https://golang.org/doc/go1.13#modules

Nota: GoSUMDB tampoco tendrá tales entradas, por lo que incluso si configura GOPROXY en un servidor que aloja este archivo y si GOSumDB está habilitado, obtendrá algo como esto:

    ➜  ~ export GOPROXY=https://gocenter.io
    ➜  ~ go get github.com/zeromq/[email protected]+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go: finding github.com/zeromq v4.2.0+incompatible
    go: finding github.com v4.2.0+incompatible
    go: downloading github.com/zeromq/goczmq v4.2.0+incompatible
    verifying github.com/zeromq/[email protected]+incompatible: github.com/zeromq/[email protected]+incompatible: reading https://gocenter.io/sumdb/sum.golang.org/lookup/github.com/zeromq/[email protected]+incompatible: 404 Not Found

La solución correcta será hacer un seguimiento con el autor del módulo para asegurarse de que están adoptando los módulos de Go correctamente agregando un sufijo al nombre del módulo.

Hay una solución, pero debe verificar si está funcionando por diseño, es decir, apunte GOPROXY a un servidor que aloje este archivo y luego use GOPRIVATE para excluir esta versión específica del módulo de la validación de GoSumDB.

[email protected]:/go# export GOPROXY=https://gocenter.io 
    [email protected]:/go# unset GOPRIVATE

    [email protected]:/go# go get github.com/zeromq/[email protected]+incompatible
    go: finding github.com v4.2.0+incompatible
    go: finding github.com/zeromq/goczmq v4.2.0+incompatible
    go: finding github.com/zeromq v4.2.0+incompatible
    go: downloading github.com/zeromq/goczmq v4.2.0+incompatible
    verifying github.com/zeromq/[email protected]+incompatible: github.com/zeromq/[email protected]+incompatible: reading https://gocenter.io/sumdb/sum.golang.org/lookup/github.com/zeromq/[email protected]+incompatible: 404 Not Found

    [email protected]:/go# export GOPRIVATE=github.com/zeromq/goczmq

    [email protected]:/go# go get github.com/zeromq/[email protected]+incompatible

    go: downloading github.com/zeromq/goczmq v4.2.0+incompatible
    go: extracting github.com/zeromq/goczmq v4.2.0+incompatible
    # pkg-config --cflags  -- libczmq libzmq libsodium
    Package libczmq was not found in the pkg-config search path.
    Perhaps you should add the directory containing `libczmq.pc'

Sin embargo, aún recomendará que se comunique con el autor del módulo para corregir el nombre del módulo en su archivo go.mod.

No se te olvide recomendar este post si lograste el éxito.

---

---

Utiliza Nuestro Buscador