Ciclo de importación no permitido

135

Tengo un problema con

ciclo de importación no permitido

Aparece cuando intento probar mi controlador. Como salida tengo

can't load package: import cycle not allowed
package project/controllers/account
    imports project/controllers/base
    imports project/components/mux
    imports project/controllers/account
import cycle not allowed
package project/controllers/account
    imports project/controllers/base
    imports project/components/mux
    imports project/controllers/account
import cycle not allowed
package project/controllers/account
    imports project/controllers/base
    imports project/components/mux
    imports project/controllers/routes
    imports project/controllers/base

¿Alguien puede decirme cómo leer o entender este error? ¿Dónde está mal la dependencia?

go codificación_cero
fuente
13
El accountpaquete importa el basepaquete, que importa el muxpaquete, que importa el accountpaquete. Es un conjunto cíclico de dependencias de importación, que no está permitido. Parece que también tienes otro ciclo, baseimportaciones mux, qué importaciones routes, qué importaciones base.
Amit Kumar Gupta

Respuestas:

170

Aquí hay una ilustración de su primer problema de ciclo de importación.

                  project/controllers/account
                     ^                    \    
                    /                      \
                   /                        \ 
                  /                         \/
         project/components/mux <--- project/controllers/base

Como puede ver con mi gráfico ASCII incorrecto, está creando un ciclo de project/components/muximportación cuando importa project/controllers/account. Como Go no admite dependencias circulares, obtiene el import cycle not allowederror durante el tiempo de compilación.

jmaloney
fuente
10
Tan malo que esto solo aparece en la compilación. Perdí mucho tiempo para reestructurar mi proyecto de pozo solo para ver que no se me permite hacer lo que hice ... dafug ...
C4d
35
Esta es una de las razones por las que no me gusta Go. Y es solo una de una docena de razones.
tom10271
13
Permitir los deps circulares aumentaría significativamente los tiempos de compilación ya que todo su círculo de deps necesitaría ser recompilado cada vez que uno de los deps cambiara. Tener deps circulares también es una gran carga cognitiva, ya que hace que sea más difícil razonar sobre su programa y tiende a la complejidad.
jmaloney
el cual linter está usando no veo ninguna pelusa en contra de código
Gopherine
Puedo ver este error al ejecutar la aplicación a través dewatcher
R Dom
98

Acabo de encontrar esto. Puede estar accediendo a un método / tipo desde el mismo paquete utilizando el nombre del paquete en sí.

Aquí hay un ejemplo para ilustrar lo que quiero decir:

En foo.go: 

// foo.go
package foo

func Foo() {...}

En foo_test.go:

// foo_test.go
package foo

// try to access Foo()
foo.Foo() // WRONG <== This was the issue. You are already in package foo, there is no need to use foo.Foo() to access Foo()
Foo() // CORRECT
Jonathan Lin
fuente
66
En mi opinión, esta es la mejor respuesta. La respuesta aceptada es igual de válida, pero no explica nada más que la teoría de tal falla. Sin embargo, la respuesta de @Jonathan Lin explica perfectamente este mensaje de error críptico y cómo combatirlo.
fantasitcalbeastly
3

Es posible que haya importado,

project/controllers/base

dentro de 

project/controllers/routes

Ya has importado antes. Eso no es compatible.

Thushara Buddhika
fuente