Por qué importar desde github.com ata tu código Go a un proveedor

Iain Cambridge, responsable de Boneclone, sostiene en su blog que los equipos que escriben Go deberían dejar de usar la URL del hosting de git como espacio de nombres y pasarse a un dominio propio. El argumento es directo: si el import path de una biblioteca es github.com/empresa/paquete, mover el repositorio a GitLab obliga a cambiar el código de todos los que la consumen, incluidas las dependencias internas.

El import path es la ubicación

Go usa la ruta del import a la vez como identificador y como dirección desde la que descargar el código. El toolchain lanza un git clone contra ese host y sigue. La ventaja es que no hace falta un registro central de paquetes y que cualquiera sabe dónde reportar un bug. La contrapartida es que la ruta deja de ser un nombre y pasa a ser una ubicación: proveedor y código quedan soldados.

Cambridge cuenta el caso de una empresa que mantenía repositorios en GitHub, GitLab y Azure DevOps a la vez porque migrar era demasiado coste. Nadie tenía tiempo y salía más barato pagar tres servicios que reescribir imports. Ese acoplamiento se termina pagando en factura.

De ahí salió Boneclone, la herramienta con la que el autor replica código esqueleto entre varias plataformas de hosting al mismo tiempo.

Dominios propios en el import path

La alternativa son dominios del tipo go.uber.org o go.mongodb.org. La ruta lógica se mantiene estable y el dominio apunta a donde toque. Cuando el repositorio se mueve, solo cambia el DNS o el HTML que se sirve.

El mecanismo es una etiqueta meta en el HTML. El toolchain pide la ruta con el parámetro go-get=1, recibe un go-import que indica qué sistema de control de versiones usar y contra qué URL clonar, y arranca desde ahí. El HTML lleva además un go-source, para que las herramientas de documentación sepan construir los enlaces al código.

Cambridge publica su configuración de nginx: una regla que responde a los visitantes humanos con un 301 hacia el repositorio y solo entrega el HTML a quien llega con el query string del toolchain, más los certificados de Let's Encrypt. También deja el index.html de ejemplo con los dos metadatos.

El coste de operación existe y no es cero. Hay que mantener ese HTML, el certificado y el DNS, y un dominio que caduque rompe builds aunque el repositorio esté intacto. Es el precio de que el nombre del paquete no lo controle un proveedor.

El consejo está pensado sobre todo para bibliotecas internas de equipos comerciales, donde el cálculo sale solo: un dominio propio cuesta menos que reescribir imports en toda la organización. Para un módulo pequeño que nadie va a mover de sitio, seguir importando desde github.com sigue siendo más cómodo, y Cambridge no lo discute.

Lo que queda en el aire es la parte organizativa. Adoptar dominios propios implica que alguien sea dueño del DNS de go.empresa.com, con su renovación y su certificado, y eso es infraestructura crítica aunque parezca una carpeta de ficheros estáticos.