Modifier un grand système de données Python sans casser l'exécution différée

## Suivre le comportement demandé jusqu'à la couche qui en est responsable Avant de modifier une vaste base de code Python consacrée aux données ou au calcul parallèle, établissez une carte propre à la tâche au lieu de lire le dépôt sans distinction. Identifiez les couches concernées : 1. Collections publiques ou interfaces destinées aux utilisateurs. 2. Expressions symboliques ou graphes de haut niveau utilisés pour la planification et l'optimisation. 3. Tâches matérialisées de bas niveau et arêtes de dépendance. 4. Ordonnanceurs ou moteurs d'exécution. 5. Couches de configuration, de répartition, de sérialisation et d'utilitaires. Suivez le comportement demandé depuis le point d'entrée public jusqu'à la plus petite couche d'implémentation qui en est responsable. Lisez les tests et la configuration adjacents avant toute modification. Naviguez en fonction de la tâche : - Comportement de l'ordonnanceur : API publiques de calcul, utilitaires de graphes, représentations des tâches, puis adaptateurs d'ordonnanceur. - Optimisation des graphes : protocoles de graphes de haut niveau, couches par blocs ou couches d'expressions, puis matérialisation. - Fonctionnalités de tableaux ou de cadres de données : API de collection, implémentation de l'opération, répartition, puis tests ciblés. - Modifications de configuration : accesseurs d'exécution, configuration par défaut, schéma et documentation. - Prise en charge d'un moteur : interface du moteur, enregistrement du point d'entrée, répartition et tests de compatibilité. Considérez les noms de modules, les nombres de lignes et les versions de dépendances mentionnés dans les notes du dépôt comme des indications de navigation, et non comme des faits immuables. Confirmez localement le code source et les manifestes actuels. Maintenez les limites des sous-systèmes explicites. Une modification d'une collection publique peut nécessiter des mises à jour correspondantes des métadonnées, du graphe, de l'ordonnanceur, des tests et de la documentation, mais ne modifiez pas les couches sans rapport. ## Utiliser les environnements du dépôt et choisir la plus petite portée de tests Utilisez le gestionnaire d'environnements et les commandes déclarés par le dépôt. Ne supposez pas qu'une installation globale de Python correspond aux combinaisons de dépendances prises en charge. Avant l'implémentation : 1. Examinez le manifeste du projet et les environnements disponibles. 2. Sélectionnez le plus petit environnement représentatif de la fonctionnalité touchée. 3. Repérez les tests, dispositifs de test, marqueurs et fonctions auxiliaires d'assertion existants les plus proches. 4. Consignez les dépendances facultatives, les indicateurs de fonctionnalité et les politiques d'avertissement pertinents. Privilégiez les scripts de commande fournis par le dépôt pour : - un seul test en échec ; - le fichier de tests du module touché ; - l'analyse du code et les vérifications statiques ; - les tests de documentation des exemples publics ; - les environnements de dépendances minimales ou de fonctionnalités facultatives ; - les vérifications plus larges équivalentes à l'intégration continue uniquement lorsque la modification les justifie. Respectez les comportements de test stricts, tels que les avertissements traités comme des erreurs, les échecs attendus stricts, les délais d'expiration et les marqueurs propres à l'environnement. Utilisez les fonctions partagées de comparaison pour les collections différées lorsqu'elles tiennent compte des métadonnées, des types, des partitions ou de la tolérance numérique. Pour les dépendances facultatives, utilisez les fonctions prévues par le projet pour importer et ignorer des tests plutôt que des conditions improvisées. Gardez à l'esprit la version minimale et la version la plus récente prises en charge lorsque vous utilisez de nouvelles API. N'installez aucun paquet, ne changez aucun environnement et n'activez aucun test dépendant du réseau, sauf si la tâche l'autorise. Signalez une dépendance manquante comme une limite de l'environnement au lieu de modifier silencieusement la machine. ## Garder l'exécution différée : ne pas appeler `compute()` en construisant les graphes Préservez l'invariant central des systèmes de graphes différés : le code de construction du graphe doit décrire le calcul sans l'exécuter. N'appelez jamais de méthodes de matérialisation immédiate telles que `compute()` ou `persist()` pendant la définition d'opérations de collection, de couches de graphes ou d'expressions symboliques. La matérialisation doit intervenir à une limite explicite de l'utilisateur ou de l'exécution. Pendant la construction du graphe : - déduisez les résultats des métadonnées chaque fois que possible ; - gardez les dépendances des tâches explicites et déterministes ; - préservez des clés stables et un comportement de tokénisation constant ; - évitez les entrées-sorties cachées ou la sélection implicite d'un ordonnanceur ; - maintenez la séparation entre l'optimisation symbolique et l'exécution de bas niveau. Suivez les conventions du dépôt : - ajoutez des annotations de type complètes au nouveau code ; - maintenez la cohérence des imports de compatibilité et des annotations différées ; - utilisez des imports protégés réservés aux types afin d'éviter les cycles ; - organisez de manière prévisible les imports issus de la bibliothèque standard, de dépendances tierces et de modules locaux ; - utilisez le style documenté des chaînes de documentation et des exemples exécutables pour les API publiques ; - respectez les conventions de nommage établies pour les fonctions auxiliaires privées, les tests et les fonctions de répartition. Lors de l'ajout d'un moteur, d'une expression, d'une couche ou d'une option de configuration, mettez à jour tous les points d'enregistrement requis et ajoutez un test ciblé prouvant que la répartition ou la planification atteint la nouvelle implémentation. Les indicateurs de fonctionnalité qui influent sur l'enregistrement au moment de l'import ou sur la planification des requêtes doivent être définis avant le premier import du module concerné. Testez le comportement avec l'indicateur activé puis désactivé lorsque les deux configurations restent prises en charge. Évitez les remaniements étendus lorsque vous corrigez un défaut ciblé. Préservez les comportements sans rapport et apportez la modification minimale qui explique le nouveau résultat du test. ## Élargir les tests pas à pas et ne jamais publier sans autorisation Augmentez progressivement le périmètre de vérification : 1. Reproduisez l'échec antérieur avec un test ciblé. 2. Exécutez le fichier de tests ou la suite du sous-système le plus proche. 3. Exécutez les analyses du code, des types ou de la documentation directement touchées par la modification. 4. Exercez les variantes pertinentes de fonctionnalités facultatives, de dépendances minimales ou d'indicateurs de fonctionnalité. 5. N'utilisez la suite complète que si la modification traverse de larges limites architecturales. Vérifiez les modes d'échec fréquents : - cycles d'import et ordre d'enregistrement ; - indicateurs de fonctionnalité modifiés après le premier import ; - métadonnées en désaccord avec les résultats calculés ; - paquets facultatifs indisponibles dans certains interpréteurs ; - contraintes de version des dépendances qui divergent entre des paquets liés ; - valeurs de configuration par défaut absentes du schéma ; - exemples de tests de documentation qui ne s'exécutent plus ; - tests qui ne réussissent qu'avec un seul ordonnanceur ou moteur. Avant d'annoncer que le travail est terminé, examinez les différences et indiquez quelles vérifications ont réellement été exécutées, lesquelles ont réussi et lesquelles n'ont pas été exécutées. Ne déduisez pas la réussite de la seule lecture du code. Le travail de publication constitue une limite d'autorité distincte. Ne créez jamais de publication, ne publiez aucun paquet, ne transmettez aucune étiquette de version, ne téléversez aucun artefact et ne modifiez aucun système externe de publication sans autorisation explicite. Si la préparation d'une publication est autorisée, vérifiez les entrées du journal des modifications, les versions et contraintes de version entre paquets, les résultats du conditionnement et la séquence documentée par le dépôt avant toute modification d'un état externe. Lorsqu'il vous est demandé de communiquer avec d'autres personnes, présentez les preuves et les options sans vous faire passer pour l'utilisateur ni inventer ses décisions.