Implications de ne pas en utilisant le chemin de prise en pension pour mes propres paquets

Question

Supposons que je décide de garder tous les paquets personnellement développés organisés comme suit:

$GOPATH/ 
    bin/ 
    pkg/ 
    src/ 
     somepkg1 
     somepkg2 
     ... 
     somepkgN 

De plus, supposons qu'il y ait beaucoup de réutilisation de code entre eux, donc je décider de conserver l'ensemble espace de travail GOPATH de $ sous le même dépôt Git (chaque paquet pourrait être un sous-module), par opposition à plus scénario traditionnel où les sous-packages sont moins cohérente (coexistant uniquement en raison de l'utilisation go get du même espace de travail):

$GOPATH/ 
    bin/ 
    pkg/ 
    src/github.com/<me>/ 
     somepkg1 
     somepkg2 
     ... 
     somepkgN 

Je vois que la première approche (ne pas utiliser github.com/<me>/ dans les chemins de paquet), go get ne serait pas en mesure d'aller chercher les paquets comme ils ne sont pas « déclarant » eux-mêmes pour être disponibles en ligne. Cependant, on peut facilement contourner cela en utilisant des sous-modules git, donc tous les paquets seraient récupérés en premier lieu (notez qu'il s'agit d'un écosystème étroitement contrôlé, donc il n'y aura pas d'affrontements de noms).

Existe-t-il une autre limitation (outre go get) de ne pas utiliser les chemins complets pour les packages?

(je suis surtout préoccupé par les limitations découlant de certains codes outils refactoring/analyse qui exploitent les repository path as base pathconvention qui permet go get de chercher le colis en ligne.)

Answer 1

Pour le compilateur Go et tous les éléments du go tool except go get le chemin d'import du paquet est une chaîne presque opaque contenant le chemin d'import. Vous pouvez disposer votre code comme vous le souhaitez (le compilateur lui-même compile les fichiers de différents dossiers en un seul paquet). Si vous n'avez pas besoin ou ne voulez pas que votre code soit go get, il n'est pas nécessaire d'utiliser un chemin repo. Les outils d'analyse et de refactoring de golang.org/x/tools fonctionnent sur les chemins d'importation opaques (pour autant que je sache) et n'accèdent pas au réseau.