J'ai un package go situé sur mon système de fichiers (pas dans le $GOPATH
), appelé bitbucket.org/me/awesome
.
~/awesome> tree
.
├── main.go
├── go.mod
├── go.sum
├── subpackageA
│ └── main.go
Ma go.mod
ressemble à:
module bitbucket.org/me/awesome
require (
... # lots of external dependencies
)
replace bitbucket.org/me/awesome => ./
Dans main.go
dans mon répertoire de niveau supérieur, j'appelle un sous-package comme suit:
import "bitbucket.org/me/awesome/subpackageA"
ce qui semble tout à fait normal. go get
travaux. Cependant, lorsque je clone l'intégralité de ce référentiel ailleurs (par exemple dans une image Docker) et que j'exécute go get
pour la première fois, j'obtiens des erreurs comme:
package bitbucket.org/me/awesome/subpackageA: https://api.bitbucket.org/2.0/repositories/me/awesome?fields=scm: 403 Forbidden
,
ce qui signifie qu'il n'utilise pas la version locale du système de fichiers des packages, même si je le lui ai dit avec la directive replace
dans le go.mod
fichier.
Qu'est-ce que je fais mal? Comment puis-je m'assurer que les sous-packages sont utilisés à partir du système de fichiers au lieu d'essayer d'être récupérés sur Internet?
Go n'a pas de notion (réelle) de "sous-paquetage". Tous les packages sont traités de manière égale. Cela signifie qu'un replace bitbucket.org/me/awesome
n'influence pas le package bitbucket.org/me/awesome/subpackageA
car il s'agit de deux packages individuels non liés. La disposition des dossiers n'introduit pas de relation de sous-paquet A avec awsome, ou l'inverse *).
Vous devez donc ajouter une directive de remplacement individuelle pour le sous-paquet A
replace bitbucket.org/me/awesome/subpackageA => ./subpackageA
*) Nitpicking pour une exactitude absolue: la disposition des dossiers a une influence pour les dossiers nommés internal
(ne peut pas être importés à partir d'autres projets), pour les dossiers nommés vendor
(qui peuvent contenir des packages fournis) et la recherche d'un go.mod
le fichier s'arrête à la racine du référentiel.