No acoples tu código Go a GitHub

Artículo original ↗ Discusión en Hacker News ↗

La práctica de Go de usar URLs completamente calificadas (a menudo rutas de GitHub) como identificadores de importación está generando preocupación por la estabilidad a largo plazo, el bloqueo con un proveedor y las migraciones dolorosas cuando los repositorios se mueven. Los comentaristas valoran alternativas como dominios personalizados, proxies internos y vendoring de dependencias, señalando compensaciones entre resiliencia, seguridad, comodidad y la carga operativa para los mantenedores. Muchos sostienen que ningún espacio de nombres es infalible, así que el verdadero reto es diseñar herramientas y flujos de trabajo que hagan manejables a lo largo del tiempo los cambios de alojamiento y la preservación de dependencias.

Rutas de importación de Go y acoplamiento a GitHub

  • El diseño de Go de “import == ruta de red” hace que el host del repositorio forme parte de la superficie de la API.
  • Muchos ven esto como frágil: pasar de GitHub a otro forge (o incluso un cambio de nombre de la organización) significa tocar rutas de importación en muchos repos y etiquetas históricas, rompiendo compilaciones antiguas.
  • Otros sostienen que el problema se exagera: una migración rara más un search/replace o go.mod replace es una sobrecarga aceptable.

Dominios personalizados / vanity URLs

  • Visión a favor de los dominios vanity: usar tu propio dominio desacopla la identidad de un forge concreto; puedes redirigir DNS o simples manejadores web (nginx, plantillas de Hugo, servidores vanity URL) a nuevos hosts más adelante, o incluso a un registro de artefactos.
  • Los críticos temen que esto solo mueva el SPOF: los dominios expiran, los registradores pueden borrar TLDs o subir precios, y los dominios abandonados pueden ser tomados y abusados.
  • Para código cerrado/interno, el control del dominio se ve como más razonable; para OSS de larga vida, algunos prefieren un “gran host estable” como GitHub.

Vendoring, proxies y reproducibilidad

  • Algunos abogan por hacer vendoring de dependencias para cada proyecto Go: mejora las compilaciones offline, la resiliencia ante la desaparición del upstream y el control de la cadena de suministro.
  • Otros señalan desventajas: repos inflados, operaciones de git y CI más lentas, trabajo manual de actualización, complejidad de dependencias recursivas.
  • El proxy de módulos de Go (proxy.golang.org) y los mirrors internos se mencionan como punto intermedio: cachear una vez y luego compilar sin tocar GitHub directamente.

Dolor de migración y escala organizativa

  • Varios comentaristas describen migraciones reales (GitHub → otro host, cambios de dominio) como “horribles” a escala, especialmente con muchos repos y versiones que dependen unos de otros.
  • Un simple search/replace falla cuando necesitas preservar la capacidad de recompilar versiones históricas; terminas ramificando/etiquetando commits antiguos solo para reescribir rutas de importación.
  • Los monorepos con una sola versión de cada dependencia evitan parte de esto, pero introducen sus propios costes.

Seguridad, integridad y diseño del sistema de paquetes

  • Se plantean preocupaciones sobre:
    • Dominios/hosts muertos o secuestrados sirviendo código malicioso.
    • La dependencia de Go de ubicaciones en lugar de identificadores estables o direccionamiento por contenido.
  • Mejoras sugeridas: imports direccionables por contenido, hashes en go.mod (no solo en go.sum), módulos firmados, mejores mecanismos de redirección/alias, o recurrir a archivos como Software Heritage.
  • Algunos ven la historia de paquetes de Go como un sistema mal diseñado que fue acumulando funciones (módulos, proxies, replace) en vez de un diseño coherente basado en un registro.