Quando o import não resolve
Os seis motivos de um adopt falhar, em ordem de frequência — e o comando que responde cada um.
Um adopt que não resolve tem sempre uma de seis causas. Elas estão em ordem de frequência.
| # | Sintoma | Causa | O que fazer |
|---|---|---|---|
| 1 | Module not found | caminho relativo errado — ele é relativo ao arquivo, e não ao diretório de trabalho | dataforge deps mostra o que cada arquivo pede |
| 2 | acha em desenvolvimento e não no CI | o pacote não está no forge.toml; funcionava pelo cache local | dataforge install numa pasta limpa |
| 3 | import cycle | A importa B, que importa A | dataforge check mostra a cadeia |
| 4 | o nome existe e o símbolo não | relay não o exporta | confira o relay do outro arquivo |
| 5 | instalação velha no PATH | há até três lugares: .venv/, ~/.dataforge/, o Python do sistema | which dataforge e dataforge --version |
| 6 | funciona no Mac e falha no Linux | maiúscula no nome do arquivo — o macOS não diferencia | renomeie tudo em minúsculas |
Onde a resolução mora#
Num lugar só: resolucao.py. Isso não é organização — é uma correção. A regra já esteve escrita em três lugares, e os três divergiram.
| Onde estava | O que dava errado |
|---|---|
| no analisador | nome.replace('.', os.sep) transformava './mod' em '//mod' — 795 de 795 avisos falsos num projeto de 21 mil linhas |
no dataforge deps | uma expressão regular que começava em [A-Za-z_], então ./vizinho nunca casava: o comando dizia “0 arquivos com imports próprios” em todo projeto |
| no interpretador | a cópia que funcionava |