Repository navigation
[P3][chore][deps] Revisar filelock 4.x depois do virtualenv >= 21.13 (a partir de 2026-10-03) — #2001 fechado, Dependabot passa a ignorar a major #2021
Description
Contexto
O PR #2001 (Dependabot: filelock 3.32.7 → 4.0.0, versão major) foi fechado por decisão do operador em 28/set/2026
por estar bloqueado, sem defeito no filelock em si.
Por que estava bloqueado (verificado)
- O
filelocké dependência apenas transitiva (huggingface-hub,python-discovery/virtualenvviapre-commit, entre
outras); não está nopyproject.toml. - O
virtualenv 21.9.0, que está nouv.lock, exigefilelock<4. Por isso o resolvedor não conseguia aceitar a 4.x, o
uv.locknão mudou e o Dependabot só alterou orequirements.txt, deixando os dois arquivos desencontrados. - O
virtualenv 21.13.0(publicado em 2026-09-26) já exigefilelock<5. Com a espera de 7 dias do repo
(cooldown: default-days: 7), ele só fica elegível a partir de 2026-10-03.
Atenção: fechar o PR faz o Dependabot IGNORAR essa versão major
Fechar (ou @dependabot close) cria uma regra de ignorar: o Dependabot não vai propor o filelock 4.x de novo sozinho.
Esta issue existe para não perdermos o assunto.
O que fazer (a partir de 2026-10-03)
- Esperar o Dependabot propor o
virtualenv≥ 21.13 (ou fazê-lo à mão, se preferir), e mesclar. - Só então tentar o
filelock4.x:uv lock --upgrade-package filelock, e regenerarrequirements.txtepylock.toml
(procedimento emdocs/ops/DEPENDABOT_REQUIREMENTS_SYNC.md). - Antes de mesclar, ler as notas de release do
filelock4.0.0. As que consultei só citam o conserto dosoft-rw, sem
lista de quebras; confirmar no changelog completo. - Se o Dependabot continuar ignorando, remover a regra de ignorar (reabrir o deps(uv): bump filelock from 3.32.7 to 4.0.0 #2001 ou
@dependabot recreate).
Critério de aceite
-
virtualenv≥ 21.13 nouv.lock. -
filelock4.x nouv.lock, comrequirements.txtepylock.tomlregenerados echeck-allcom exit 0.
— Claude (Opus 5.5, T14) · auditor, tom recomendatório
Activity
FabioLeitao commentedon Oct 11, 2026
Resultado da tentativa (2026-10-11, executada pelo Cursor no epic #2055, branch local; nada foi commitado).
virtualenv 21.14.6já aceitafilelock<5, então o bloqueio original (virtualenv 21.9.0exigindofilelock<4) deixou de existir.filelock4.x não entra no lock estável: osnowflake-connector-pythonestável (4.8.0, último no PyPI) ainda exigefilelock>=3.5,<4.filelock>=4(uv lock --upgrade-package 'filelock>=4') resolveu, mas não limpo. O delta nouv.lockfoi:filelock 3.32.7 → 4.1.0,virtualenv 21.9.0 → 21.14.6,snowflake-connector-python 4.7.4 → 5.0.0rc5(release candidate),protobuf 7.34.1 → 6.33.6(downgrade) e a remoção deboto3,botocore,s3transfer,jmespatheasn1crypto.uv.lockfoi revertido ao estado doHEAD.Leitura: um GA não deve arrastar uma pré-release do conector nem um downgrade de
protobufsó para subir ofilelock. Recomendo manter o item aberto e reavaliar quando osnowflake-connector-pythonestável liberarfilelock>=4(a 5.0 sair de rc). Até lá, o #2001 (Dependabot) continua corretamente fechado.Recomendatório; a decisão é do operador.
FabioLeitao commentedon Oct 12, 2026
Reprodução em 2026-10-12 (Claude, tom recomendatório)
Mesmo resultado do comentário de ontem, numa cópia temporária (nada tocado no repo):
uv lock --upgrade-package filelocknão muda nenhum pacote; forçarfilelock==4.0.3resolve, mas comsnowflake-connector-python 4.8.0 → 5.0.0rc5(pré-release),protobuf 7.34.1 → 6.33.6(downgrade),virtualenv 21.9.0 → 21.14.7e remoção deboto3,botocore,s3transfer,jmespatheasn1crypto.Nota: o Dependabot reabriu o assunto em #2031 (
filelock 4.0.3), porque o ignore criado ao fechar o #2001 vale para aquela versão. Ele só editarequirements.txt, então segue inaplicável.Opção, decisão do operador: acrescentar
filelock(major) aoignorede.github/dependabot.yml, no mesmo molde deebcdic,chardeterpds-py, para parar de reabrir a cada patch. O arquivo não está na lista de gate. Remover o ignore quando o conector estável liberarfilelock>=4.