Improving the daily stubtest check for third-party stubs

Ouverte
  • Quelque chose ne va pas ?
#14,838 3 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
testing-qa, tooling

Piste de recherche

Commencez par localiser l’implémentation de stubsabot et la vérification quotidienne de stubtest, puis suivez la manière dont les versions des paquets et les plages prises en charge sont découvertes. Examinez le chemin existant de création des issues et l’intégration des releases de paquets. Le travail est terminé lorsque les nouveaux releases déclenchent des vérifications pour les stubs tiers concernés, tandis que les échecs dans la plage prise en charge ouvrent des issues spécifiques au paquet sans répétition nocturne.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

project: infrastructure

Currently, stubtest checks the stdlib and all third-party stubs daily and will create a new issue if there are discrepancies. While this is fine for the stdlib, it gets annoying for third-party stubs, and doesn't scale well. We either need to fix third-party stubs to a fixed version, which is often overly specific and causes a new stubsabot issue whenever a new micro version is released, or we need to use a range, which has the danger of triggering a new issue daily until fixed. It also means that third-party stubs get checked every night, no matter whether a new package was released or not.

Instead I suggest we extend stubsabot to run on every newly released package version. If the new release is outside the supported version range of the stubs, stubsabot will function as it does now. If the new release is within the supported version range, stubsabot will run stubtest against the new package and open an issue specific for that package if stubtest fails.

This would make fixing these issues less pressing, but also enable us to use more relaxed version ranges. Changes in the "most annoying" packages often only concern internal API and/or are backwards compatible. In the future, we might even consider opening up the ranges more, for example by using >= X.Y.Z, < (X-1) for packages following semver.

Langage dominant
Python
Étoiles
5.1k
Forks
2.1k
Merge moyen
2 j 1 h
PR mergées (30 j)
115

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de python/typeshed

Toutes les issues de python/typeshed

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.