Python 3.15.0 chega ao GitHub Actions: já dá para atualizar a matriz de testes

Apareceu no repositório actions/python-versions um commit com a build estável do Python 3.15.0. A novidade é restrita, mas, para milhares de projetos no GitHub, é um sinal: já dá para adicionar "3.15" à matriz de testes e verificar o código no interpretador mais recente, sem precisar compilá-lo por conta própria. O desenvolvedor Simon Willison esperava por esse momento havia alguns dias. Ele chegou a pedir ao ChatGPT que clonasse o repositório, fizesse um git pull a cada hora e avisasse quando a 3.15 estável finalmente aparecesse.

Por que o release do

Python e a disponibilidade no CI não coincidem

Quando uma nova versão sai no python.org, o GitHub Actions não a recebe de imediato. O action setup-python pega as builds prontas do interpretador no manifesto do repositório actions/python-versions. Enquanto não existir ali um registro do 3.15.0, o comando `python-version: "3.15"` ou procura apenas pré-releases ou não encontra nenhuma versão compatível. Os mantenedores precisam gerar as distribuições para Linux, macOS e Windows, rodar as verificações e fazer o commit da atualização.

Foi exatamente esse passo que Willison esperou. O release já tinha saído e a página no python.org já existia, mas o CI ainda não conseguia usá-lo. Para autores de bibliotecas, essa defasagem é incômoda: os usuários instalam o novo Python nos primeiros dias, e é melhor detectar um bug de compatibilidade antes deles.

Como o ChatGPT virou vigia de repositório

O prompt de Willison parece quase uma tarefa de cron escrita em linguagem natural: clonar https://github.com/actions/python-versions, executar git pull a cada hora até que a 3.15 estável seja adicionada e, então, avisá-lo. Ele publicou o link da conversa. É um exemplo cotidiano de cenário agêntico: o modelo recebe acesso a um ambiente com git, repete uma ação em intervalos regulares e volta por conta própria com o resultado quando a condição é atendida.

A tarefa é pequena, mas ilustrativa. Antes, esse tipo de coisa se resolvia com assinatura de releases, RSS ou um script em servidor. Agora basta descrever a condição em palavras. A desvantagem também é clara: a confiabilidade desse vigia depende de como o produto de chat planeja e dispara as verificações repetidas. A assinatura de notificações do GitHub ou um workflow próprio agendado entregam um resultado mais previsível. A nota de Willison não informa o resultado da verificação, então não há como avaliar a eficácia da abordagem.

O que você precisa saber sobre a configuração

• A versão deve ser indicada como string: `"3.15"`. Sem aspas, o YAML pode ler o número como float, e `3.10` vira `3.1`. Essa armadilha é conhecida há muito tempo.
• Origem das builds: o manifesto em actions/python-versions, usado pelo setup-python.
• Página do release: python.org/downloads/release/python-3150.
• Tags da nota: GitHub, Python, GitHub Actions, ChatGPT.

Na prática: o que fazer hoje

Se você mantém uma biblioteca ou um serviço em Python, adicione `"3.15"` à matriz, por exemplo `python-version: ["3.13", "3.14", "3.15"]`. O melhor é marcar a primeira execução como não bloqueante com `continue-on-error`. Assim, dependências com extensões nativas que quebrarem não vão parar o pipeline principal. Os wheels para a nova versão não aparecem de imediato nos pacotes populares, e as primeiras builds vermelhas costumam ter essa causa, e não o seu código.

Vale também revisar os avisos de depreciação que o Python emitiu nas versões anteriores. É mais fácil corrigi-los agora, antes que a API antiga seja removida. Se você tem builds noturnas ou testes em imagens Docker, adicione a 3.15 a eles também.

Por fim: se você espera um evento em um repositório alheio, não é obrigatório pedir isso a um chatbot. A assinatura de releases ou um workflow agendado simples é mais confiável, e o chatbot serve quando a condição é difícil de descrever de modo formal.