La plupart des langages et outils de programmation prennent en charge le concept de packages et la plupart du temps, ces packages ont des versions. L’avantage des versions, qu’elles soient utilisées par des outils ou non, est qu’elles permettent aux développeurs de communiquer clairement les dépendances nécessaires à la génération du produit final.

Depuis ses débuts, Go a eu beaucoup de mal à gérer les versions, ce qui a conduit les développeurs à construire leurs propres outils, comme gb et glide. Début 2017, l’équipe Go a lancé Dep, qui constituait l’expérience officielle de gestion des packages dans Go. Les leçons tirées de Dep, et d’autres langages, ont conduit à la proposition officielle des modules Go qui ont été introduits dans Go 1.11.

Alors, quel est le problème ?

Ne vous méprenez pas, je suis très enthousiaste à propos de l’introduction des modules Go car ils résolvent un tas de problèmes. Cela nous éloigne également du concept affreux de la gestion des fournisseurs. Soyons honnêtes, qui veut garder une copie des sources de chaque dépendance dans son projet, risquer de perdre toutes les dépendances (nous avons appris de left-pad, n’est-ce pas ?) ou voir ses collègues essayer un peu les nouvelles versions ?

Ce sont là autant de problèmes que les modules Go résolvent, et ils introduisent même une variable d’environnement appelée GOPROXY qui permet aux développeurs d’envoyer toutes les demandes de téléchargement de modules via un proxy. En soi, c’est évidemment génial pour les entreprises qui veulent garder un cache des versions (et ne pas télécharger la dépendance à chaque fois), garder un œil sur la sécurité (et limiter l’accès à Internet depuis leurs serveurs de build), et bien d’autres raisons. Il y a juste un petit problème, cependant. Le GOPROXY est difficilement utilisable.

Le problème avec GOPROXY

Actuellement, l’utilisation de GOPROXY est un exercice de style « tout ou rien ». Cela signifie que toutes les dépendances de l’ensemble de votre arborescence de dépendances (directes et transitives) doivent être résolues à partir de ce serveur proxy et que le client Go échouera si l’une des dépendances n’est pas présente dans ce Registre Go.

En d’autres termes, si quelqu’un construit une nouvelle application avec labstack/echo v3.3.5 et dgrijalva/jwt-go v3.2.0 dans son fichier go.mod et exécute go install avec la variable GOPROXY, le client go échouera à moins que les deux modules, leurs versions requises et toutes leurs dépendances transitives soient disponibles sur ce proxy. Ainsi, à moins d’être absolument certain que l’ensemble de mon arborescence de dépendances peut être résolue à partir du serveur proxy, qui peut être interne ou externe, cette approche ne fonctionnera pas.

Solutions de secours

Comme pour tout problème, il doit exister une solution, n’est-ce pas ? En effet ! En fait, la solution existe déjà. Un fil de discussion dans le dépôt Golang sur GitHub (lancé par Aaron Schlesinger de l’équipe d’Athènes), décrit le problème et la solution pour permettre aux proxies de ne fournir que certains modules. Si l’on reprend l’exemple précédent, si l’un des deux modules est disponible sur le proxy et que l’autre ne l’est pas, le build aboutira. Un module sera téléchargé à partir du proxy et l’autre sera téléchargé à partir d’un système de contrôle de version.

La possibilité de disposer d’une telle solution de secours résoudrait une partie du problème. Certains proxys de module Go, comme Athens, seront en mesure de construire des fichiers go.mod vides à partir de ces demandes non résolues, ce qui provoque à son tour d’autres problèmes.

Finaliser la solution

La solution idéale permettrait aux utilisateurs de spécifier leur GOPROXY, d’utiliser des solutions de secours au cas où le module ne serait pas disponible et, ce qui est important, de télécharger ces modules sur le proxy. Cette approche signifie que le téléchargement d’une version d’un module ne sera effectué que par un seul développeur et qu’il sera ensuite disponible dans le serveur proxy pour être utilisé par d’autres développeurs et serveurs CI. Étant donné que certaines entreprises ne permettent pas à leurs serveurs de CI de se connecter à Internet, cela résoudrait vraiment le problème et rendrait les modules Go irréprochables pour les développeurs. Si vous vous demandez à quoi cela peut ressembler, consultez CLI JFrog qui intègre toute cette logique. Je pense que nous sommes tous d’accord cependant, que c’est une caractéristique que nous attendons du langage lui-même….