Go: Proposition : prise en charge des "liens symboliques" dans GOPATH

Créé le 2 mai 2016 · 3Commentaires · Source: golang/go

Au dos de https://github.com/golang/go/issues/15201#issuecomment -208602586

Nous proposons un moyen par lequel cmd/go et ses amis exploitent des fichiers réguliers pour simuler un comportement de type lien symbolique dans un référentiel lors de la résolution du package GOPATH d'une manière indépendante de la plate-forme.

https://docs.google.com/document/d/1n5y3mZPs_4PjI80a0vZEaHLe7r9PeiiE9xsIrQFT8Is/edit

Merci à @kardianos d'avoir partagé ses premières réflexions hors ligne

_Le nom "lien symbolique" est lié à susciter une bonne discussion en soi : j'espère que nous pourrons discuter des noms/noms séparément du cœur de la proposition_

FrozenDueToAge Proposal

Source

myitcv

👍2

Tous les 3 commentaires

Quelques commentaires/questions :

Le terme "répertoire" n'est pas défini. Que se passe-t-il si le code source de GOPATH ne provient pas d'un VSC ou de Subversion qui prend en charge l'extraction d'un répertoire ?
si un référentiel contient plusieurs binaires publics, il n'est pas nécessaire de copier les dépendances plusieurs fois. les dépendances vendues peuvent être placées sous cmd/vendor.
Autant que je sache, cette proposition ne résout pas le problème "bibliothèque et programme dans le même référentiel".

kostya-sh le 2 mai 2016

👍1

@kostya-sh

Le terme "répertoire" n'est pas défini

La première note de bas de page donne des détails - c'est la même définition que celle supposée ici . Mais je suis d'accord que la question demeure de savoir si le "référentiel" est formellement défini quelque part ?

Que se passe-t-il si le code source de GOPATH ne provient pas d'un VSC ou de Subversion qui prend en charge l'extraction d'un répertoire ?

Question ouverte - j'admets que la seule considération jusqu'à présent a été pour le code qui fait partie d'un "dépôt". J'ai ajouté une section "questions ouvertes" en bas faisant référence à cette question.

si un référentiel contient plusieurs binaires publics, il n'est pas nécessaire de copier les dépendances plusieurs fois. les dépendances vendues peuvent être placées sous cmd/vendor

En effet, c'est une approche pour partager le code fourni entre les binaires. Mais l'approche "symlink" aide à faciliter l'approche de partage de ce "fournisseur" avec le code de la bibliothèque (voir point suivant)

Autant que je sache, cette proposition ne résout pas le problème "bibliothèque et programme dans le même référentiel".

Cette proposition en elle-même ne le fait pas, non. Mais le référentiel lié à la section "Exemple motivant" décrit comment ce problème peut être résolu en utilisant une combinaison de "liens symboliques" et d'augmentation GOPATH.

myitcv le 2 mai 2016

Les liens symboliques sont trop problématiques. Il semble imprudent de les autoriser.