No acoples tu código Go a GitHub
Don't couple your Go code to GitHub
En Go, los imports como "github.com/usuario/repo" atan tu código a un proveedor de git. Si migras a GitLab, todos los imports deben cambiar, lo que genera una dependencia costosa. La solución es usar dominios propios como go.tudominio.com, que redirigen a cualquier hosting. El autor comparte su configuración de Nginx y el HTML con metadatos go-import para implementarlo fácilmente.
En mi opinión, todo equipo de desarrollo de software comercial que use Go debería usar dominios personalizados para nombrar sus librerías y paquetes internos.
- jerf
Esto se esconde en la ofuscación de ser demasiado específico. El problema es general. Para nombrar un paquete, uno debe estar en un espacio de nombres de algún tipo. Como el universo no proporciona ningún tipo de "espacio de nombres" ambiental abstracto al que todos podamos apelar, todos los espacios de nombres son constructos humanos. Como constructos humanos, pueden fallar.
En esta terminología, el artículo básicamente equivale a decir "¡Este espacio de nombres puede fallar! ¡La solución es usar otro!"
Pero eso no te lleva a ningún lado, porque el nuevo espacio de nombres también puede fallar. De hecho, es casi seguro que fallará antes que "el DNS y el hosting de github.com" como espacio de nombres.
No hay solución en la que vincules el lanzamiento de tu software a un espacio de nombres que no pueda fallar porque no existe un espacio de nombres que no pueda fallar. No importa si tu lenguaje favorito usa DNS o tiene un repositorio central bendecido o si distribuye una lista bendecida de nombres de paquetes con el propio lenguaje o cualquier otra cosa. El espacio de nombres puede fallar.
Por lo tanto, lo único que realmente puedes hacer es ser resiliente a los fallos, y en muchos sentidos, la única solución práctica para la resiliencia es simplemente asumir que si, en el futuro, alguien tiene problemas para obtener un paquete debido a un fallo del espacio de nombres, no se desintegrará indefenso en un charco de lágrimas mientras tu código se pierde para siempre, sino que la persona del futuro resolverá este problema perfectamente solucionable.
- rot256
La gestión de paquetes en Go siempre se sintió bastante chapucera. Entre los problemas está la confusión entre "qué es algo" y "dónde está algo". Al principio ni siquiera había una forma de tener diferentes versiones de un paquete, con la justificación de que simplemente deberías fijar una interfaz y mantenerla estable hasta el fin de los tiempos; tampoco había forma de "bloquear dependencias", así que en el momento de la compilación obtenías lo que ese repositorio te sirviera. Ha mejorado desde entonces, pero aún hay cierta chapucería como resultado de "hacer crecer" un sistema de paquetes.
- thih9
> En mi opinión, todo equipo comercial de desarrollo de software que use Go debería usar dominios personalizados para nombrar sus bibliotecas y paquetes internos.
Eliminaría "Go" de lo anterior, es decir, creo que lo mismo se aplica a otros stacks.
Incluso usar enlaces de dominio de GitHub en los comentarios del código se vuelve problemático a largo plazo. Por ejemplo, cuando ocurre una migración y esos enlaces empiezan a no apuntar a ningún lado.
- dewey
> Es decir, si trasladas tu hosting de git a GitLab, ¡tienes que cambiar tu código!
También puedes simplemente usar "replace github.com/example/example => gitlab.com/example/example" en tu archivo go.mod y todo seguirá funcionando. Eso parece una optimización muy prematura para algo que realmente no importa.
- farthest
Entonces, ¿qué pasa cuando el proveedor de dominio es comprado y el dominio de tu proyecto de código abierto se subasta y se compromete? Esto parece ser tortugas hasta el fondo...
- p4bl0
Cierto, pero cuidado con el nombre de dominio que usas. Porque VeriSign puede decidir unilateralmente eliminar tu nombre de dominio junto con miles de otros [1] y vuelves al punto de partida...
- unscaled
> Una de las buenas características de Go es que pones tu código en un espacio de nombres con la ubicación para obtener el código.
Luego el resto del artículo explica por qué esto NO es una buena característica en la práctica.
Tampoco creo que sea inviable, pero esta es una de esas pequeñas cosas que Go decidió hacer diferente y convenció a sus fans de que es una gran idea y de que todos los demás lenguajes lo estaban haciendo mal. Después de que aparecieron un par de baches, en lugar de admitir que hay algunas ventajas en tener nombres de paquetes oficiales, ahora se nos dice que todo el mundo debería simplemente configurar su propio dominio personalizado con un servidor nginx o un reenviador de Go Vanity URLs para servir tráfico a sus paquetes alojados en GitHub.
- st3fan
Genial cuando una empresa quiebra y los dominios quedan colgando. El siguiente que lo recoja se hace cargo del código fuente del que otros ahora dependen. Hemos visto esto muchas veces ya en otros ecosistemas. Es una situación muy mala.
Es un mal consejo mover tus paquetes bajo tu propio dominio. Nunca serás tan bueno como Microsoft para seguir pagando por el dominio. No hay garantías en la vida, pero te garantizo que cuando quiebres, ese dominio será lo último en lo que pensarás.