Mise à jour du développement de crates.io

 (blog.rust-lang.org)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Au cours des six derniers mois, crates.io a introduit un visualiseur de code source permettant d’examiner directement les packages publiés ainsi qu’un système de comptes indépendant de GitHub, et a renforcé les indications liées à la sécurité et aux alternatives dans la bibliothèque standard
  • Le nouvel onglet Code prend en charge la recherche de fichiers, la coloration syntaxique et la sélection de lignes partageable ; grâce aux manifestes ZIP et JSON du CDN et aux requêtes HTTP par plage, il ne charge que les fichiers nécessaires sans solliciter les serveurs d’API
  • Conformément à la RFC #3946, l’implémentation de noms d’utilisateur propres à crates.io a commencé ; après le changement de nom d’utilisateur et une revue de sécurité, la prise en charge de fournisseurs d’authentification autres que GitHub est prévue
  • Le frontend a été entièrement migré d’Ember.js vers Svelte, et la recherche, la consultation des dépendances inverses, la mise en cache CDN et le traitement de l’index Git ont aussi été améliorés pour accroître les performances et la fiabilité
  • Les avertissements d’abandon de maintenance de RustSec et les API de remplacement dans la bibliothèque standard, comme std::sync::LazyLock, sont affichés sur les pages des packages afin de faciliter l’audit des dépendances et la suppression des dépendances inutiles

Un visualiseur de code source pour examiner les packages publiés

  • Le nouvel onglet Code des pages de packages permet de parcourir, dans crates.io, les fichiers de chaque version publiée
    • Il affiche non pas le dépôt associé, mais les fichiers réellement téléchargés lorsque cargo ajoute une dépendance
    • Il devient plus facile d’auditer les dépendances, car on peut aussi consulter des fichiers absents du dépôt, comme le Cargo.toml normalisé généré par cargo
  • Le visualiseur prend en charge la recherche dans l’arborescence de fichiers, la coloration syntaxique et la sélection de lignes à la manière de GitHub
    • Cliquer sur des numéros de ligne ou les faire glisser génère une URL partageable de la forme #L10-L20
  • Le serveur génère, pour toutes les versions publiées, des fichiers ZIP et des manifestes JSON décrivant la structure des fichiers
    • Les fichiers .crate utilisés par cargo étant des tarballs compressés en gzip qui ne prennent pas en charge l’accès aléatoire, ils sont reconditionnés en arrière-plan sous forme de ZIP explorable
    • Les ZIP et les manifestes sont servis via un CDN statique
    • Le frontend récupère d’abord le manifeste, puis charge chaque fichier uniquement à la demande au moyen de requêtes HTTP par plage
    • La navigation dans le code n’ajoute pratiquement aucune charge aux serveurs d’API de crates.io, et les anciennes versions sont également traitées par lots afin de prendre en charge les anciennes releases
  • La bibliothèque de rendu du visualiseur de code est à l’origine un moteur de rendu de différences, et un visualiseur de comparaison entre versions utilisant la même infrastructure est également en cours de développement
    • Une fois terminé, il permettra d’examiner dans crates.io les changements exacts entre deux versions publiées

Des comptes crates.io indépendants de GitHub

  • L’équipe crates.io a approuvé fin mai la RFC #3946
  • Jusqu’à présent, la connexion GitHub et l’identité crates.io étaient fortement couplées, et le nom d’utilisateur était déterminé par le compte GitHub ; la RFC introduit des noms d’utilisateur propres à crates.io, indépendants des comptes liés
  • Ces noms d’utilisateur propres constituent un prérequis à la prise en charge, à l’avenir, de connexions via des fournisseurs d’authentification autres que GitHub
  • L’implémentation a commencé, mais le changement de nom d’utilisateur reste la principale fonctionnalité visible par les utilisateurs qui n’est pas encore terminée
    • Une fois celle-ci achevée, une RFC supplémentaire et une implémentation concernant la connexion via d’autres fournisseurs d’authentification seront lancées
    • Comme cela touche directement à l’authentification et à la sécurité des comptes, le déploiement se fait lentement, par petites étapes soigneusement examinées

Avis de sécurité et indications d’alternatives dans la bibliothèque standard

  • L’onglet Security existant affiche les avis de sécurité de la base de données RustSec ; désormais, les packages que RustSec marque comme abandonnés affichent aussi une bannière d’avertissement en haut de page
    • La bannière mène à l’avis correspondant, qui contient les détails et les alternatives possibles
  • Les packages dont la fonctionnalité a été intégrée à la bibliothèque standard affichent une bannière “You might not need this dependency”
    • Par exemple, lazy_static peut être remplacé, depuis Rust 1.80, par std::sync::LazyLock
    • Dans la liste des dépendances, les packages remplacés sont accompagnés d’une petite icône d’ampoule fournissant la même indication
  • Les données associées sont gérées dans le nouveau dépôt rust-lang/std-replacement-data
    • Seules les entrées de remplacement par la bibliothèque standard sont acceptées
    • Chaque entrée doit citer l’API stabilisée de std, core ou alloc ainsi que la version de Rust correspondante
    • Avant d’ajouter une entrée, les mainteneurs du package doivent être informés et disposer d’un délai pour donner leur avis
    • De nouvelles entrées peuvent être proposées dans le dépôt, et les données accumulées pourront aussi être utilisées par d’autres outils

Migration du frontend vers Svelte terminée

  • L’expérience consistant à migrer le frontend de crates.io d’Ember.js vers Svelte s’est achevée avec succès
    • Le nouveau frontend a atteint un niveau équivalent à celui des fonctionnalités existantes
    • Après un test public en avril, il est devenu le frontend par défaut début mai
    • L’application Ember.js a été supprimée du dépôt
  • Il s’agit d’une migration à l’identique de la conception et des fonctionnalités existantes, conçue pour que les utilisateurs ne ressentent pas le changement
  • L’équipe et les contributeurs peuvent désormais utiliser un framework moderne tout en abaissant la barrière d’entrée pour les nouveaux contributeurs et en accélérant les cycles de développement ; le visualiseur de code source en est un exemple
  • Des remerciements sont adressés à la fois à l’équipe Ember.js, utilisée par crates.io pendant de nombreuses années, et à l’équipe Svelte, qui a soutenu la transition

Page d’erreur Ferris

  • Ferris sur les pages d’erreur de crates.io suit désormais le curseur de la souris avec ses yeux
  • Même la page d’erreur 404 propose ainsi une petite interaction

Performances de la recherche et de la consultation des dépendances inverses

  • La recherche par pertinence calculait auparavant le classement de tous les packages correspondant au terme de recherche, ce qui pouvait prendre 1 à 2 secondes pour les termes courts ou fréquents
    • Le calcul du classement est désormais limité aux 1 000 packages correspondants ayant le plus grand nombre de téléchargements récents
  • L’endpoint des dépendances inverses ne recalcule plus, à chaque requête, l’ensemble complet des packages dépendants
    • Il sert les résultats depuis une table précalculée synchronisée par des triggers de base de données
    • Cela remplace des jointures coûteuses par des scans d’index limités, réduisant fortement le risque de timeout

Documentation d’architecture et rendu Markdown

  • ARCHITECTURE.md a été entièrement remanié pour se concentrer sur les systèmes de haut niveau de crates.io et sur la façon dont ils sont interconnectés
    • Le déroulement du traitement lors de l’exécution de cargo publish
    • La raison pour laquelle les téléchargements ordinaires de packages ne passent pas par les serveurs d’API
    • La manière dont le nombre de téléchargements est calculé à partir des journaux d’accès du CDN
  • Les README rendent désormais les listes de définitions, une extension Markdown largement utilisée
    • Le moteur de rendu Markdown comrak prenait déjà en charge les listes de définitions, mais cette extension n’était pas activée

Amélioration de l’efficacité du cache CDN

  • Des métadonnées de balises de cache sont ajoutées aux fichiers téléversés vers le CDN statique
    • Au lieu d’envoyer une requête d’invalidation distincte pour chaque URL de fichier, il est possible d’invalider en une seule fois tous les fichiers en cache d’un package ou d’une release donnée
  • L’en-tête de réponse global Vary: Cookie, qui empêchait la mise en cache CDN des réponses de l’API publique et des assets frontend, a été supprimé
    • Les réponses propres à un utilisateur appliquent à la place Cache-Control: no-store
    • Le taux de cache hit en périphérie du CDN s’en trouve amélioré

Accessibilité et traitement de l’index Git

  • L’accessibilité de crates.io a été améliorée pour les utilisateurs de lecteurs d’écran
    • Les icônes décoratives sont masquées dans l’arbre d’accessibilité
    • La hiérarchie des titres a été corrigée
    • Le bon balisage de liste est appliqué aux listes
    • Des tests par snapshots ARIA ont été introduits afin d’éviter que des régressions soient intégrées sans être détectées
    • L’accessibilité continuera d’être améliorée au cours des prochains mois
  • Les copies locales de l’index Git utilisées par les workers en arrière-plan ont été converties en dépôts bare et shallow
    • Environ 250 000 fichiers checkoutés et l’historique complet des commits ont été supprimés du disque
    • Cela améliore les performances de traitement alors que la fréquence de publication des packages augmente
  • Le squash périodique de l’index utilise désormais l’API GitHub au lieu de générer localement un gros pack Git
    • L’ancienne méthode de génération locale du pack avait déjà provoqué des erreurs de mémoire insuffisante sur les workers de production

Canaux de feedback

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • Je suis content de voir que le travail pour dissocier les comptes crates.io de GitHub est en cours

    • Avant, j’aimais bien la connexion via un compte GitHub sur plusieurs services, mais aujourd’hui cela me paraît moins attrayant. Tailscale prend en charge les fournisseurs d’identité OIDC, donc je l’ai configuré pour se connecter via Codeberg et le WebFinger de mon domaine.
      Pour se connecter avec l’adresse e-mail de mon propre domaine example@example.com, il suffit de placer sur https://example.com/.well-known/webfinger un fichier JSON dont le subject est acct:example@example.com et dont le href de l’émetteur OpenID Connect est https://codeberg.org.
      Dans les paramètres de Codeberg, il suffit ensuite de créer une application OAuth2 avec comme URI de redirection https://login.tailscale.com/a/oauth_response, puis de saisir dans Tailscale le Client ID et le Client Secret générés. Il semble que crates.io proposera bientôt quelque chose de similaire

  • Je ne pensais pas que l’ampleur des améliorations récentes de crates.io était à ce point importante. Jusqu’ici, je commençais généralement par lib.rs, mais cela pourrait bientôt changer, et la modification que je préfère est Ferris

    • Je me demande quelle part de ces améliorations est due à l’introduction d’agents

  • Le changement dans les yeux de Ferris n’est pas vraiment cohérent physiquement. Les parties blanches dans les yeux noirs sont des reflets spéculaires ; à moins que le curseur de la souris soit la source lumineuse, on peut difficilement dire que les yeux suivent le curseur

  • Quand j’audite des dépendances, je commence par créer un lien symbolique de ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ vers ~/cargosrc afin d’accéder facilement aux fichiers téléchargés par Cargo.
    Pour chaque dépendance à auditer, je clone le dépôt Git, je checkout la version cible, je supprime localement les fichiers suivis, puis j’envoie SIGSTOP au processus rust-analyzer. J’ajoute la dépendance au Cargo.toml du projet et j’exécute cargo fetch, puis je copie le contenu du répertoire téléchargé $dependency-$version dans le dépôt cloné, je le commit, et j’examine les différences dans un visualiseur d’historique Git.
    Une fois l’examen terminé, j’enregistre via un script la combinaison dépendance/version/hash de Cargo.lock dans une base de données de confiance afin de ne pas revérifier la même version. La procédure semble compliquée, mais j’en ai automatisé la majeure partie, ce qui la rend plus efficace qu’une interface web, et j’aimerais que Cargo prenne en charge ce type de procédure de revue en ligne de commande. Je me demande aussi s’il existe un plugin qui aide à la revue elle-même, plutôt qu’un outil comme cargo-crev

  • L’implémentation où le frontend ne récupère d’abord que le manifeste, puis charge chaque fichier à la demande via des requêtes HTTP par plage se trouve ici, et elle utilise le DecompressionStream intégré au navigateur