Quelle version de Go est utilisée pour compiler les dépendances ?

l'éditeur php Baicao répondra à votre question sur la version de Go à utiliser pour compiler les dépendances. Lors de la compilation du code Go, le choix des versions de dépendances est crucial. Il est généralement recommandé d'utiliser des versions de dépendances compatibles avec les versions Go connues pour s'exécuter de manière stable dans votre projet. Cela garantit la stabilité et la compatibilité du code. Dans le même temps, vous devez également vous demander si les dépendances utilisées sont toujours en maintenance et s’il existe des mises à jour compatibles avec la dernière version de Go. Compte tenu de manière globale des exigences du projet et des caractéristiques des dépendances, le choix de la version Go appropriée pour compiler les dépendances peut garantir au maximum le fonctionnement stable du projet.

Contenu de la question

Lors de la compilation d'un programme Go, utilisez-vous la même version de Go pour compiler le code principal et le code dépendant ?

Solution

C'est une question intéressante et a une réponse quelque peu subtile.

Pour les anciennes versions de Go, la réponse est simple : chaque dépendance est compilée en utilisant la version de Go que vous exécutez localement. Si vous exécutez Go 1.9 et que vous avez des dépendances créées pour Go 1.10, le compilateur n'essaiera pas judicieusement de compiler le code Go 1.10 à l'aide de Go 1.9. Tant qu'aucune nouvelle fonctionnalité n'est utilisée dans cette dépendance, tout fonctionnera correctement. De même, si vous avez une dépendance écrite pour Go 1.8, elle sera également compilée avec Go 1.9.

Cependant, pour les versions modernes de Go et tout projet (ou dépendance) qui utilise des fichiers go.mod, le comportement est différent. De la Référence du module Go nous apprenons :

• Pour les packages contenus dans des modules, le compilateur refuse d'utiliser les fonctionnalités du langage introduites après la version spécifiée par la directive go. Par exemple, si un module a la directive go 1.12, son package ne peut pas utiliser les littéraux numériques introduits dans Go 1.13, tels que 1_000_000.

Cela signifie que votre dépendance utilisera uniquement les fonctionnalités disponibles dans sa version Go déclarée. Cependant, ils sont toujours construits à l’aide du runtime Go moderne. Par conséquent, toutes les améliorations de performances, améliorations de sécurité, etc. trouvées dans votre version Go (plus récente que la version déclarée par la dépendance) seront toujours utilisées.

De plus, la ligne suivante du même document dit :

• Si une ancienne version de Go crée un package d'un module et rencontre une erreur de compilation, l'erreur indiquera que le module a été écrit pour une version de Go plus récente. Par exemple, supposons que la version du module soit 1.13 et que le package utilise le littéral numérique 1_000_000. Si le package est construit avec Go 1.12, le compilateur indiquera que le code a été écrit pour Go 1.13.

Cela signifie donc que si vous essayez de créer un programme avec Go 1.19 et que l'une des dépendances déclare la version 1.20 et qu'il y a une erreur de compilation, la sortie du compilateur vous informera des problèmes de compatibilité potentiels. S'il n'y avait pas d'erreurs de compilation, vous ne remarqueriez peut-être jamais la différence (car les dépendances qui pourraient être déclarées pour la version 1.20 n'utilisent en réalité aucune des nouvelles fonctionnalités du compilateur 1.20).

Cela aura un impact plus notable qu'avant, probablement dans Go 1.22, en supposant que la proposition de portées de variables de boucle moins sujettes aux erreurs soit acceptée et mise en œuvre à temps. Étant donné que cette proposition changerait la façon dont les variables de boucle sont gérées d'une manière non rétrocompatible. En supposant que cela arrive à Go 1.22, cela signifie que tout module déclaré go 1.21 或更早版本的模块都将使用旧的循环语义，任何声明 go 1.22 ou supérieur utilisera la nouvelle sémantique de boucle. Ce serait la première fois que Go viole sa promesse de compatibilité ascendante, bien que sans doute pour une bonne raison (puisque cette variable de boucle a causé des ennuis à presque tout le monde).

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!