Improving the daily stubtest check for third-party stubs

Aberta
  • Algo errado?
#14,838 3 comentários 2 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
30/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
python
Domínio
testing-qa, tooling

Direção de pesquisa

Comece localizando a implementação do stubsabot e a verificação diária do stubtest; depois, acompanhe como as versões dos pacotes e os intervalos suportados são descobertos. Revise o fluxo existente de criação de issues e a integração com releases de pacotes. O trabalho estará concluído quando novos releases dispararem verificações para stubs de terceiros afetados, enquanto falhas dentro do intervalo suportado abrirem issues específicas do pacote sem repetição noturna.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
5.1k
Forks
2.1k
Merge médio
2d 1h
PRs com merge (30d)
115

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de python/typeshed

Todas as issues de python/typeshed

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.