Parte 12

Reconstrua seu ambiente, não a sua memória

A automação mais valiosa nem sempre é uma tarefa do negócio. Às vezes é poder chegar a uma nova conta de hospedagem, colocar um Core pequeno, executar uma receita explícita e recuperar as ferramentas e hábitos em que você confia.

Seu ambiente é uma receita mais estado

Módulos instalados, pacotes de interface, scripts de inicialização e preferências descrevem como o terminal se comporta. Arquivos do projeto e bancos de dados são outra camada de estado. Separar essas ideias torna migração e recuperação muito mais simples.

Registre o que deve ser recriado automaticamente e o que precisa voltar de uma cópia de segurança. Uma receita de instalação descreve ferramentas e valores padrão seguros; não deve levar dados da aplicação nem credenciais para um novo servidor.

Antes de escrever uma receita, inspecione o ambiente que você já usa

core dá uma visão compacta de Core, interface e módulos; install -l lista os módulos e pacotes instalados; include mostra como os pacotes de interface estão armazenados; e upgrade -c verifica as versões atuais sem gravar nada.

Esse inventário separa “acho que preciso destas ferramentas” de uma lista realmente reproduzível. Remova hábitos obsoletos antes de fixá-los na automação da instalação.

core

install -l

include

upgrade -c

`setup.lil` é uma preparação executada uma única vez, não um script permanente de inicialização

O Core atual percebe um setup.lil regular ao lado de lil.php, executa-o depois da autorização quando necessário e só o remove quando todos os comandos terminam com sucesso. Se o Installer completo não estiver presente, o Core pode buscá-lo e retomar a operação original de instalação.

Mantenha o arquivo de instalação explícito. Um install em lote é compacto e legível; versões exatas com -v podem ser usadas quando você realmente precisa de uma receita travada. Não coloque senhas, chave privadas nem credenciais de banco específicas do projeto nesse arquivo.

install help history upgrade dir pwd md mf edit find stat hash run

`autoload.lil` serve para pequenas ações recorrentes no início da sessão

run verifica autoload.lil uma vez por sessão autorizada e não o apaga. Isso o torna adequado a verificações leves ou preparação de ambiente que deve se repetir, não a instalação feita uma única vez.

upgrade -auto check é um bom exemplo: ele administra um pequeno bloco em autoload.lil e verifica atualizações uma vez por sessão. Atualização automática é uma política mais forte e continua opcional; ambientes importantes normalmente ficam melhores com verificação, revisão e só então atualização.

upgrade -auto check

upgrade -info

Reprodutibilidade é saber que liberdade você escolheu

install <mod> seleciona a versão pública compatível atual; install <mod> -v <ver> solicita um número publicado específico. As duas formas continuam respeitando a geração ativa do Core e as dependências do módulo.

Os marcos anteriores da geração 1 permanecem apenas como histórico e não são mais destinos de instalação. A versão suportada é a atual. A partir do próximo lançamento, versões numeradas devem permanecer disponíveis como destinos exatos, a menos que uma versão seja retirada explicitamente.

install hash -i

install hash -v 1.1.3

A interface do navegador é uma camada de pacote, não o ambiente de execução dos comandos

include administra pacotes CSS/JavaScript componíveis como lil, hotkeys e code. O modo de sessão é temporário; -s cria a composição persistente .lil.css e .lil.js.

Essa separação ajuda ao mudar de servidor: módulos PHP podem estar corretos mesmo sem seu pacote de interface preferido. Reconstrua primeiro a funcionalidade e depois a apresentação. Se a camada de interface ficar confusa, kill -include redefine apenas essa camada sem apagar o Core.

include -l

include lil -i

include -lil -s

Uma receita de instalação só está pronta depois de ser testada em um lugar descartável

A melhor prova é uma instalação limpa: publique um Core novo, execute a receita e compare core, install -l e upgrade -c com o ambiente que você pretendia reproduzir.

Testar a receita encontra dependências invisíveis — aquele comando instalado manualmente meses atrás, o pacote de interface esquecido ou a extensão disponível em um servidor e ausente em outro. Reprodutibilidade é descoberta reconstruindo, não declarando.