Pitch: Criei o sora, uma ferramenta pra rodar comandos de distrobox como se fossem nativos do host (Silverblue, Bazzite, Bluefin...)

Fala pessoal, primeiro post meu aqui no TabNews.

Uso Bluefin no dia a dia. Pra quem não conhece: em distros imutáveis/atômicas (Silverblue, Bazzite, Bluefin, MicroOS, Vanilla OS) o sistema base é somente leitura, e a forma idiomática de instalar ferramentas é dentro de containers com distrobox. Funciona muito bem, até você perceber que passa o dia digitando:

distrobox enter archbox -- nvim

O problema

O ecossistema já resolveu a direção container → host (distrobox-host-exec, host-spawn). A direção host → container continua manual, e as soluções que encontrei caem em dois grupos:

• Resolvers ingênuos de command-not-found: encaminham qualquer palavra desconhecida pra um container, mesmo quando nenhuma box tem aquele pacote. Um typo como gti status acorda um container parado só pra falhar de um jeito confuso.
• Resolvers ansiosos: exportam wrappers pra ~/.local/bin via distrobox-export. Isso polui o PATH, inverte a precedência quando o nome colide com um binário do host e deixa wrapper órfão quando você remove o pacote na box.

De onde veio (e por que "sora")

O empurrão final foi outro projeto meu: estou desenvolvendo uma distro imutável baseada em fedora-bootc, a Kuuhaku OS. Como usuário de Bluefin, esse atrito do distrobox sempre me incomodou, e eu queria que o meu sistema já viesse com algo que resolvesse isso de fábrica. Só que nada existente funcionava do jeito que eu achava certo, então escrevi o CLI eu mesmo.

Ele nasceu com o nome "kuu" e depois virou "sora": o primeiro kanji de Kuuhaku (空白) é 空, que sozinho se lê "sora". Ou seja, sim, a ferramenta carrega literalmente um pedaço do meu nick.

O que eu construí

Criei o sora: uma vez configurado, você digita o comando e, se não existir no host, ele roda transparentemente da box que tem o pacote.

O host sempre vence, e isso é estrutural: o hook de command-not-found só dispara depois que o PATH do host já falhou, então nada consegue sombrear um binário nativo.

• A resolução usa um índice cacheado comando → box: um typo custa microssegundos e nunca acorda container.
• Comando em mais de uma box? Resolve por pin → prioridade → ordem alfabética (sora pin python archbox, sora conflicts, sora which).
• O índice se atualiza sozinho: sora box create instala um hook dentro da box no próprio gerenciador de pacotes (dnf5, apt, pacman), então cada install/remove reescreve o índice no host.
• Pra scripts, .desktop e cron (onde hook de shell não existe) tem o sora anxious, que exporta um comando específico de forma explícita. O caso de uso principal são gerenciadores de pacote: depois de sora anxious --sudo pacman --box archbox, um pacman -S steam direto no terminal do host simplesmente funciona.
• Shell puro, sem daemon, sem compilação. MIT.

curl -fsSL https://raw.githubusercontent.com/LLawli/sora/main/packaging/install.sh | sh
sora box create archbox --image arch
sora hook install

Limitações

• A resolução tardia só funciona em shell interativo com o hook instalado (é exatamente por isso que o anxious existe).
• No fish, o $status de um comando resolvido pelo hook reporta 127 mesmo quando rodou com sucesso (o comando executa e imprime normalmente, só o status mente). bash e zsh propagam certo.
• Gerenciadores fora de dnf5/apt/pacman (zypper, apk...) ainda precisam de sora reindex manual.

Feedback que eu procuro

A ferramenta nasceu de uma dor minha e quero saber se ela faz sentido pra mais gente: o modelo de resolução tardia te parece correto? Que gerenciador de pacotes você sente falta no auto-reindex? Tem algum caso de uso que os dois modos não cobrem?

Repositório: https://github.com/LLawli/sora (README também em PT-BR)