web-dev-qa-db-fra.com

Utilisation de sous-packages avec go mod localement

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?

7
atp

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.

6
Volker