Distribuir a ferramenta

Do .df no seu computador ao comando que outra pessoa instala.

Uma ferramenta que só roda na sua máquina é um script. Três formas de entregá-la, em ordem de esforço:

O projeto#

$ dataforge new cli minha-ferramenta
$ cd minha-ferramenta
$ dataforge test
$ dataforge run src/main.df -- --ajuda

O -- separa o que é do dataforge do que é seu: sem ele, --ajuda seria lido pela CLI da linguagem, e a sua nunca veria a flag.

Empacotar e publicar#

$ dataforge pack
$ dataforge publish --registry=../registro

O tarball é reprodutível (mtime=0, uid e gid zerados): sem isso o sha256 mudaria a cada empacotamento, e a verificação de integridade do forge.lock não significaria nada.

Um contêiner que não precisa do DataForge instalado#

$ dataforge devops dockerfile
$ docker build -t minha-ferramenta .
$ docker run --rm minha-ferramenta --ajuda

O Dockerfile gerado copia o manifesto antes do código (um commit numa linha deixa de reinstalar tudo), roda como USER forge — um escape de container vira um usuário sem privilégio, e não root no host — e põe o .env no .dockerignore, porque o segredo ficaria na camada e docker history o mostraria.

O que conferir antes de publicar#

adopt Arcane.Abi as Abi

// 'Abi' responde qual bump de semver a mudança exige, comparando a
// SUPERFÍCIE de duas versões — e não o texto do código.
assert "maior" in Abi.regras() or len(Abi.regras()) > 0
out "as regras de compatibilidade estão em Arcane.Abi"

• dataforge test e dataforge check verdes.
• dataforge abi entre a versão publicada e esta — renomear um parâmetro é quebra, porque a chamada com nome existe nesta linguagem.
• A ajuda cita cada opção, e os exemplos rodam.
• O forge.lock versionado: quem clonar em outro dia recebe a mesma árvore.