Um arquivo TOML mudou o que o Sweep era

O Sweep começou com uma suposição muito conveniente.

Eu era o usuário.

Se eu achava que imagens pertenciam a um diretório e arquivos compactados a outro, o programa podia simplesmente saber disso, porque eu tinha escrito no código.

Não havia divergência entre as preferências de quem escreveu e as de quem usava.

Eram a mesma pessoa, sentada na mesma mesa, olhando para o mesmo diretório Downloads terrível.

Isso funcionou surpreendentemente bem até eu adicionar configuração.

01.As regras estavam escondidas no código

A primeira versão do Sweep precisava de regras para classificar arquivos e decidir para onde eles deveriam ir.

Deixar essas regras fixas no código não pareceu, a princípio, um problema de design.

Pareceu programação.

O projeto era pequeno, o comportamento estava mudando e eu ainda estava aprendendo o que queria que ele fizesse. Editar o Python sempre que eu mudava de ideia não era um grande peso, porque o repositório já estava aberto.

Mas preferências fixas no código têm uma consequência silenciosa.

O programa não consegue distinguir entre:

é assim que o Sweep funciona

e:

é assim que eu organizo meus arquivos hoje, por acaso

Essas regras não são do mesmo tipo.

Uma pertence à ferramenta.

A outra pertence a quem a está usando.

Enquanto eu era a única pessoa envolvida, era muito fácil ignorar essa distinção.

01.1Então apareceu um arquivo TOML

Um trabalho recente adicionou o carregamento de configuração usando o tomllib do Python.

No nível mais mecânico, isso significa que o Sweep consegue ler TOML, em vez de exigir que toda preferência more dentro do código-fonte Python.

Essa parte é agradavelmente comum.

O arquivo passa pelo parse.

O Python entrega dados ao programa.

O Sweep pode usar esses dados ao decidir como deve se comportar.

Mas, no momento em que os valores passaram a vir de fora do código, deixaram de ser detalhes privados de implementação.

Viraram entrada.

E entrada tem opiniões.

Ela pode estar ausente.

Pode estar malformada.

Pode ser um TOML válido e ainda assim não fazer sentido para o Sweep.

Pode nomear uma categoria que o resto do programa não entende.

Pode omitir algo que antes existia como uma constante indiscutível no código.

O parse do arquivo responde a uma pergunta bem pequena:

isto é TOML?

Ele não responde:

esta é uma configuração que o Sweep sabe usar?

Essa segunda pergunta agora pertence ao Sweep.

01.2Configuração é uma interface

Eu costumava pensar em configuração como tirar valores do código-fonte.

Pegar uma constante daqui.

Colocar num arquivo ali.

Parabéns, o programa é configurável.

Esse modelo ignora a parte incômoda.

Quando existe um arquivo de configuração, o formato e o significado desse arquivo viram uma pequena interface entre o usuário e o programa.

O programa precisa decidir o que significa um valor ausente.

Talvez exista um valor padrão.

Talvez o valor seja obrigatório.

Talvez a funcionalidade correspondente deva ser desativada.

São três comportamentos diferentes, e o parser de TOML não pode escolher entre eles por mim.

Valores inválidos criam o mesmo problema.

Rejeitá-los é fácil de dizer. Produzir um erro que explique qual parte é inválida e o que o Sweep esperava é outro trabalho.

Depois há regras e categorias desconhecidas.

Ignorar uma delas pode fazer a configuração parecer funcionar enquanto o Sweep silenciosamente faz outra coisa. Rejeitar todo valor desconhecido é mais seguro, mas isso também significa que o formato de configuração precisa ser definido com cuidado suficiente para que a rejeição seja útil.

A compatibilidade também aparece, eventualmente.

Se eu mudar mais tarde a forma como uma regra é representada, um arquivo de configuração antigo não deixa de existir só porque o novo design parece mais bonito.

O Sweep ainda não tem respostas finais para todas essas perguntas.

Adicionar TOML não resolveu a configuração.

Fez o problema de configuração ficar visível.

01.3Algumas decisões devem ficar no programa

A configuração externa cria outra tentação: tornar tudo configurável.

Todo diretório.

Todo nome.

Todo conflito.

Toda pequena ramificação que um dia possa incomodar alguém.

Isso certamente eliminaria as preferências fixas no código.

Também poderia trocar um pequeno organizador de arquivos por uma linguagem para descrever organizadores de arquivos.

Eu já estou projetando uma linguagem de programação. Não preciso que o arquivo de configuração do Sweep vire outra por acidente.

Algum comportamento ainda pertence ao código.

Regras de segurança são o exemplo mais claro. Uma preferência pode descrever para onde uma categoria deve ir. Isso não significa que a configuração deva contornar casualmente o comportamento conservador que impede o Sweep de sobrescrever um arquivo existente.

A configuração pode expressar escolhas dentro da ferramenta.

Ela não deve fazer a ferramenta deixar de ser a ferramenta.

Ainda não sei exatamente onde essa fronteira vai se assentar.

Agora, o Sweep consegue carregar TOML. Essa é a parte que existe.

Ainda preciso decidir quais valores são obrigatórios, quais valores ausentes devem usar padrões e quais configurações devem ser rejeitadas. O Sweep também precisa dizer algo útil quando não consegue usar o arquivo que recebeu.

E ainda preciso decidir onde a configuração termina e o comportamento comum do programa começa.

O tomllib não pode responder nada disso por mim.

Ele consegue fazer o parse do arquivo.

O resto continua em aberto.