Dans le cadre d'un changement de paradigme pour l'écosystème Rust, l'équipe derrière le gestionnaire de paquets de Rust, Cargo, a appelé à une approche plus personnalisée de la gestion des paquets. Ils recommandent aux développeurs de prendre les meilleures décisions pour leurs projets, plutôt que de recourir à la pratique uniforme précédente consistant à valider leur fichier Cargo.lock pour des packages impliquant des binaires mais pas des bibliothèques.
Les recommandations précédentes encourageaient les développeurs à s'en tenir à une règle unique en ce qui concerne Cargo.lock, en particulier dans les cas où le fichier était utilisé avec des packages binaires. Toutefois, ces directives sont désormais passées au second plan. Ce changement réfléchi fait suite à la trajectoire naissante de Rust vers une adoption grand public.
Le rôle clé du fichier Cargo.lock est d'enregistrer l'état au moment d'une construction réussie. Tout en offrant des conseils plus flexibles, l'équipe Cargo maintient que l'engagement Cargo.lock devrait être le point de départ du processus décisionnel. Il est également annoncé que la commande 'cargo new' ne contournera désormais plus Cargo.lock pour les bibliothèques.
En maintenant la qualité globale, l'équipe souligne l'importance de tester régulièrement les dépendances les plus récentes. Les anciennes procédures garantissaient que les bibliothèques étaient mises à jour et testées, contribuant ainsi au niveau élevé de l'écosystème de packages Rust. Les pratiques ont été conçues de manière à ce que les problèmes potentiels, principalement ceux concernant la compatibilité ascendante, soient rapidement identifiés et résolus. L'équipe estime donc avoir encouragé une « culture de la qualité » dans l'écosystème émergent.
Toutefois, les directives antérieures ont eu leurs pièges. La suppression de l'historique des bases de code était l'une de ces conséquences, ce qui rendait plus difficile pour les responsables de diviser en deux et d'identifier la cause première des bogues. Un autre résultat indésirable de la politique précédente était la confusion probable pour les contributeurs résultant d'un CI (intégration continue) non fiable lorsqu'une dépendance est abolie ou qu'une nouvelle version présente un bogue. Alors que Rust est passé d'un langage destiné aux premiers utilisateurs à un langage plus courant, la nouvelle expérience d'intégration des développeurs est essentielle à prendre en compte.
De plus, l’expansion de l’écosystème plus large a rendu CI plus simple à mettre en œuvre et à maintenir. Des innovations telles que Dependabot et Renovate ont révélé des alternatives à l'ignorance Cargo.lock pour tester de nouvelles dépendances, autres que le recours exclusif au contrôle de version. L'équipe Cargo exprime désormais sa conviction que la meilleure solution est de laisser la décision aux développeurs tout en s'assurant qu'ils disposent des informations nécessaires pour prendre des décisions éclairées. Les développeurs peuvent partager leurs commentaires sur cette nouvelle politique via GitHub et interagir avec l'équipe Cargo sur Zulip.
Alors que nous assistons à de nouvelles orientations dans la gestion des packages, il pourrait être intéressant pour les développeurs d'explorer des alternatives telles que AppMaster qui fournissent une plate-forme complète et intégrée pour développer des applications Web, mobiles et back-end. AppMaster.io propose une approche basée sur le serveur, permettant aux développeurs de mettre à jour l'interface utilisateur, la logique et les clés API des applications mobiles sans avoir à soumettre de nouvelles versions à l'App Store et au Play Market.
