Go: Propuesta: apoyar "enlaces simbólicos" en GOPATH

Algunos comentarios/preguntas:

• El término "repositorio" no está definido. ¿Qué sucede si el código fuente en GOPATH no proviene de un VSC o de Subversion que admita la verificación de un directorio?
• si un repositorio contiene varios binarios públicos, no es necesario copiar las dependencias varias veces. las dependencias de proveedores se pueden colocar en cmd/vendor.
• Por lo que puedo decir, esta propuesta no resuelve el problema de "biblioteca y programa en el mismo repositorio".

@kostya-sh

El término "repositorio" no está definido

La primera nota al pie brinda detalles: es la misma definición que se asume aquí . Pero estoy de acuerdo en que la pregunta sigue siendo si "repositorio" se define formalmente en alguna parte.

¿Qué sucede si el código fuente en GOPATH no proviene de un VSC o de Subversion que admita la verificación de un directorio?

Pregunta abierta: admito que la única consideración hasta ahora ha sido el código que forma parte de un "repositorio". He agregado una sección de "preguntas abiertas" en la parte inferior que hace referencia a esta pregunta.

si un repositorio contiene varios binarios públicos, no es necesario copiar las dependencias varias veces. las dependencias vendidas se pueden colocar en cmd/vendor

De hecho, ese es un enfoque para compartir código de proveedor entre binarios. Pero el enfoque de "enlace simbólico" ayuda a facilitar el enfoque de compartir ese "proveedor" con el código de la biblioteca (consulte el siguiente punto)

Por lo que puedo decir, esta propuesta no resuelve el problema de "biblioteca y programa en el mismo repositorio".

Esta propuesta por sí sola no, no. Pero el repositorio vinculado desde la sección "Ejemplo motivador" describe cómo se puede resolver ese problema mediante el uso de una combinación de "enlaces simbólicos" y aumento GOPATH.

Los enlaces simbólicos son demasiado problemáticos. Me parece imprudente permitirlos.