Guide de développement de la bibliothèque de code#

Code de conduite#

La qualité du code ne réside pas seulement dans ce que vous écrivez, mais aussi dans la manière dont vous l’écrivez. Pendant les tests d’intégration continue, plusieurs outils vérifieront votre code pour détecter des erreurs de style. Un bon style de programmation est l’une des exigences pour soumettre du code à Xinference.

De plus, n’apportez pas de modifications soudaines au code, car cela pourrait entraîner des problèmes avec une grande partie du code utilisateur. Par conséquent, nous devons maintenir autant que possible la compatibilité ascendante afin d’éviter des pannes à grande échelle.

Correction automatique des erreurs de format#

De plus, l’intégration continue exécutera des outils de vérification du formatage du code tels que black, flake8, isort en utilisant pre-commit hooks. Tout avertissement généré par ces vérifications entraînera l’échec de l’intégration continue. Par conséquent, il est recommandé d’exécuter ces vérifications vous-même avant de soumettre du code. Cela peut être fait en installant pre-commit dans le répertoire racine du dépôt Xinference :

pip install pre-commit

Exécutez ensuite la commande :

pre-commit install

Une fois installé, cela garantit que chaque soumission de modification exécutera automatiquement toutes les vérifications de style, sans avoir à les lancer manuellement une par une. De plus, l’utilisation de pre-commit vous permet de rester facilement synchronisé lorsque nos vérifications de code changent.

Veuillez noter que, si nécessaire, vous pouvez ignorer ces vérifications en utilisant la commande git commit --no-verify.

Si vous ne souhaitez pas inclure pre-commit dans votre flux de travail, vous pouvez toujours exécuter la commande suivante pour l’utiliser comme vérification :

pre-commit run --files <files you have modified>

sans avoir à exécuter pre-commit install au préalable.

Si vous souhaitez exécuter une vérification sur tous les fichiers récemment soumis, vous pouvez utiliser la commande suivante :

pre-commit run --from-ref=upstream/main --to-ref=HEAD --all-files

sans avoir à exécuter pre-commit install au préalable.

Note

Vous pouvez envisager d’exécuter régulièrement la commande pre-commit gc pour nettoyer les dépôts qui ne sont plus utilisés.

Note

Si vous avez installé une version conflictuelle de virtualenv, cela peut entraîner des erreurs - veuillez vous référer ici .

De plus, en raison d’un bug dans virtualenv, vous pourriez rencontrer des problèmes si vous utilisez conda. Pour résoudre ce problème, vous pouvez rétrograder virtualenv à la version 20.0.33.

Rétrocompatible#

Veuillez maintenir la rétrocompatibilité autant que possible. Si vous estimez qu’une modification est nécessaire, expliquez clairement les raisons dans la requête de tirage (pull request). Soyez prudent lors de la modification de la signature des méthodes et ajoutez des avertissements d’obsolescence si nécessaire. En outre, ajoutez des directives Sphinx d’obsolescence pour les fonctions ou méthodes dépréciées.

Vous devez également

  1. Écrire un nouvel exemple de test qui émet un avertissement lors de l’appel d’un paramètre obsolète.

  2. Mettez à jour tous les exemples de test et le code Xinference existants pour utiliser les nouveaux paramètres.

Indication de type#

Xinference encourage fortement l’utilisation d’annotations de type de style PEP 484. Les nouveaux développements doivent inclure des annotations de type, et les demandes de tirage qui annotent le code existant sont également les bienvenues !

Développement piloté par les tests#

Xinference accorde une grande importance aux tests et encourage vivement les contributeurs à adopter le « développement piloté par les tests (TDD) <https://en.wikipedia.org/wiki/Test-driven_development> ». Ce processus de développement « repose sur la répétition de cycles de développement très courts : d’abord, le développeur rédige un cas de test automatisé (initialement échouant) pour définir l’amélioration souhaitée ou la nouvelle fonctionnalité, puis utilise le minimum de code pour passer ce test. » Par conséquent, avant d’écrire du code, vous devez rédiger vos cas de test. En général, les cas de test peuvent être extraits de l’issue GitHub d’origine. Cependant, il convient d’envisager des scénarios supplémentaires et d’écrire les cas de test correspondants.

Après avoir poussé le code vers Xinference, il est souvent demandé d’ajouter des exemples de test. Par conséquent, il est très important de prendre l’habitude d’écrire des exemples de test à l’avance, afin d’éviter tout problème.