Google prévoit d'apporter un support plus affiné aux modules dans Go 1.12

L'entreprise donne des détails aux développeurs

Go 1.11, publié en août 2018, introduit un support préliminaire pour les modules. Pour l'instant, la prise en charge des modules est maintenue parallèlement aux mécanismes traditionnels basés sur GOPATH. La commande go utilise par défaut le mode module lorsqu'elle est exécutée dans des arborescences de répertoires situées en dehors de GOPATH / src et marquées par des fichiers go.mod dans leurs racines. Ce paramètre peut être remplacé en définissant la variable d'environnement de transition $ GO111MODULE sur on ou off; le comportement par défaut est le mode automatique. L’équipe responsable de Go indique qu’elle a déjà constaté une adoption importante des modules dans la communauté Go, ainsi que de nombreuses suggestions utiles et des rapports de bogues ayant pour optique de l’aider à améliorer les modules.

Go 1.12, prévu pour février 2019, affinera le support du module mais le laissera toujours en mode automatique par défaut. Outre de nombreuses corrections de bogues et autres améliorations mineures, le changement le plus important dans Go 1.12 est que des commandes telles que go run x.go ou go get rsc.io/2fa@v1.1.0 peuvent désormais fonctionner en mode GO111MODULE = on sans fichier go.mod explicite.

Intégration IDE et outillage

L’équipe rappelle que depuis huit ans qu’elle a lancé GOPATH, un nombre incroyable d’outils a été créé, qui suppose que le code source de Go est stocké dans GOPATH. Le passage aux modules nécessite donc la mise à jour de tout le code qui en découle. C’est pour cela qu’elle a conçu un nouveau paquetage, golang.org/x/tools/go/packages, qui résume l’opération de recherche et de chargement d’informations sur le code source Go d’une cible donnée. Ce nouveau paquet s'adapte automatiquement au mode modules et à GOPATH et est également extensible aux dispositions de code spécifiques aux outils, telles que celle utilisée par Bazel. L’équipe a travaillé de concert avec des auteurs d’outils de toute la communauté Go pour les aider à adopter golang.org/x/tools/go/packages dans leurs outils.

La transition vers les modules et les modifications du chargement des packages ont également entraîné une modification importante de l'analyse du programme Go. Dans le cadre de la refonte de go vet pour prendre en charge les modules, l’équipe a introduit un framework généralisé pour l’analyse incrémentielle des programmes Go, dans lequel un analyseur est appelé pour un package à la fois.


Index du module

Une des parties les plus importantes de la conception initiale de go get était sa décentralisation : Google pensait alors (et l'équipe affirme encore y croire) que quiconque devrait pouvoir publier son code sur n'importe quel serveur, contrairement aux registres centraux tels que Perl. CPAN, Maven de Java ou Node NPM. En plaçant les noms de domaine au début de l'opération, l'espace d'importation a été réutilisé dans un système décentralisé existant et vous évitait de devoir résoudre à nouveau les problèmes de choix des utilisateurs. Cela permettait également aux entreprises d'importer du code sur des serveurs privés, parallèlement à du code provenant de serveurs publics. Il est essentiel de préserver cette décentralisation lorsque nous passons aux modules Go.

La décentralisation des dépendances de Go a eu de nombreux avantages, mais elle a également présenté quelques inconvénients importants. La première est qu’il est trop difficile de trouver tous les packages Go disponibles au public. Chaque site qui souhaite fournir des informations sur les packages doit effectuer sa propre analyse ou attendre que l'utilisateur lui pose des questions sur un package en particulier avant de le récupérer.

Aussi, l'équipe travaille sur un nouveau service : l'index...