Comment les modules Go gèrent-ils les référentiels privés et le rôle obsolète de GOPATH ?

Modules Go, référentiels privés et rôle de GOPATH

Dans la transition du gestionnaire de dépendances dep vers les modules Go, comprendre les implications La moduleisation sur la structure du code et les dépendances est cruciale. Cet article approfondit les nuances de l'utilisation des modules Go avec des dépendances internes stockées dans des référentiels privés.

Dotless Paths et le référentiel standard

Les modules Go ont été conçus dans le but de en réservant les chemins sans point (par exemple, mycompany/mylib) pour la bibliothèque standard uniquement. Cela découle de l'attente selon laquelle la plupart des projets utilisant des modules importeraient des dépendances à partir de référentiels publics à l'aide de go get. Cependant, les dépendances internes présentent un scénario différent.

Modules et GOPATH

Les modules Go visent à fournir un système de gestion des dépendances standardisé qui simplifie la gestion des versions et réduit le besoin d'intervention manuelle. . Lorsqu'un projet utilise des modules, cela implique que toutes les dépendances doivent également suivre le système de modules. Le GOPATH, tout en servant toujours de cache pour les modules téléchargés, perd son rôle précédent de résolveur de dépendances principal.

Dépôts privés et développement hors ligne

Utilisation de référentiels privés pour les dépendances internes introduisent le besoin d’authentification. Bien que la gestion du référentiel privé dans les modules Go soit encore en cours de développement, des solutions de contournement telles que l'utilisation de variables d'environnement (par exemple, GITHUB_TOKEN) et la configuration des URL Git peuvent être utilisées.

De plus, les problèmes liés au développement hors ligne peuvent être résolus via le $ Variable d'environnement GOPROXY, comme indiqué dans le billet de blog de Russ Cox sur vgo. En définissant $GOPROXY de manière appropriée, les dépendances peuvent être mises en cache localement, permettant le développement hors ligne tout en utilisant des référentiels privés.

Résolution des dépendances

Avec les modules activés, Go suppose que toutes les dépendances doivent être résolu à l’aide du système de modules. Cela signifie que les développeurs ne peuvent plus compter sur GOPATH pour résoudre des dépendances telles que mycompany/mylib dans l'exemple fourni.

Pour résoudre ce problème, il est nécessaire de déplacer la dépendance interne (par exemple, mylib) hors de le GOPATH ou le déclarer explicitement comme dépendance dans un fichier go.mod dans le fichier de dépendance répertoire.

Conclusion

Les modules Go offrent une manière structurée de gérer les dépendances, en particulier pour les projets qui s'appuient sur des référentiels publics. Cependant, l'utilisation de modules Go avec des dépendances internes dans des référentiels privés nécessite des considérations supplémentaires en matière d'authentification, de développement hors ligne et de résolution des dépendances. En tirant parti de solutions de contournement telles que GITHUB_TOKEN et $GOPROXY, les développeurs peuvent relever ces défis et adopter une approche cohérente de la gestion des dépendances.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!