delonix init
Começa o projecto CERTO para este directório — detecta, explica-se, e delega.
Start the RIGHT project for this directory — detect, explain, dispatch.
O stack init já gera um projecto completo e preenchido, e o
vm init faz o mesmo para uma VM. O que faltava era o passo ANTES desses: saber qual
deles chamar, e com qual dos onze templates. É esse o trabalho todo aqui — detectar,
dizer o que detectou e porquê, e delegar. Não gera nada de seu.
A detecção lê os manifestos do projecto — as dependências declaradas em
package.json, composer.json, pyproject.toml ou
requirements.txt — porque o nome de um ficheiro não diz que framework o projecto
usa. Um manifesto que não nomeia nenhum framework com template é desconhecido: recebe o
scaffold genérico, com a razão escrita, nunca o template que sobrou. Um -t explícito
ganha sempre à detecção. E explica-se sempre: um palpite errado que se vê é um palpite que se
corrige com -t; um palpite errado em silêncio produz um projecto que não bate certo
com o código ao lado.
Há um caso em que a resposta certa é não gerar nada: um directório com
docker-compose.yml já corre nativamente com delonix compose up, e um
segundo manifesto deixaria o projecto com duas fontes de verdade. O comando di-lo, em vez de
gerar na mesma.
O que é substituído nos ficheiros é verificado antes de se escrever o primeiro: o nome do
projecto tem de ser um rótulo DNS (minúsculas, dígitos e hífens interiores — vira nome de
container, tag de imagem e nome de pacote; --name dá-lhe outro), e o -v
tem de ser uma versão simples dentro da gama que o template declara. Num projecto já existente
só entra a cola do Delonix; a CI do template só é escrita se o projecto não tiver CI própria e
usar o mesmo gestor de pacotes.
stack init already generates a complete, filled-in project, and
vm init does the same for a VM. What was missing is the step BEFORE those: knowing
which one to call, and with which of the eleven templates. That is the whole job here — detect,
say what was detected and why, and dispatch. It generates nothing of its own.
Detection is a pure function over the file names present, ordered most-specific first (a Django
project also has .py files, and a Next.js one also has package.json — the
broader rule must not win just because it was checked earlier). And it always explains
itself: a wrong guess you can see is a wrong guess you can override with -t,
while a silent one just produces a project that does not match the code sitting next to it.
There is one case where the right answer is to generate nothing: a directory with
a docker-compose.yml already runs natively under delonix compose up, and
a second manifest would leave the project with two sources of truth. The command says so instead
of generating anyway.
📄 Implementação real em Rust: cmd/init.rs
Usage: delonix init [OPTIONS] [DIR]
Arguments:
[DIR]
Project directory (default: the current one)
Options:
--name <NAME>
Project name (default: the directory's name). Lowercase letters, digits and inner hyphens, because it becomes a container name, an image tag and a package name
-t, --template <TEMPLATE>
Force a template instead of the detected one (`stack init -t list` shows them)
-v, --template-version <TEMPLATE_VERSION>
Version parameter some templates read — an image tag, a framework version, or a toolchain version, depending on the template; the exact accepted form is documented in that template's own README. Refused with a clear error on a template that has none
--force
Overwrite files that already exist
--port <PORT>
Host and container port of the service, instead of the template's own
--tls-port <TLS_PORT>
HTTPS port, on a template that serves TLS (nginx, httpd, haproxy)
--hostname <HOSTNAME>
Extra host name or address for the generated TLS certificate (repeatable; localhost is always included)
-h, --help
Print help (see a summary with '-h')
EXAMPLES:
# look at this directory and start the right project for it, saying what it
# detected and why
delonix init
# a directory other than the current one
delonix init ./myapp
# override the guess when the detection picked the broader rule
delonix init -t go
# regenerate on top of files that already exist
delonix init --force
# adopt an EXISTING project — only the Delonix/CI glue is written, the
# project's own code is untouched
delonix init ./my-existing-app
# pick the template's version — an image tag for `odoo` (Odoo 20 when
# omitted)
delonix init -t odoo -v 19.0
# ...or an image tag for `wordpress` (WordPress 6.7 when omitted)
delonix init -t wordpress -v 6.7 myblog
# ...or a bare major/major.minor for `django`, pinned as `==X.Y.*`
delonix init -t django -v 5.2 myapp
# ...or a framework version for `laravel`/`nextjs`/`nestjs`/`node`
delonix init -t laravel -v 12.5 myapp
# an HTTPS edge on ports of your choice, with a certificate that also covers
# your own name
delonix init -t nginx --port 9080 --tls-port 9443 --hostname shop.test edge
# ...or a Go toolchain version — this template has no framework to pin
delonix init -t go -v 1.27 myapp
# choose the project name — without --name it comes from the directory,
# lowercased and hyphenated when needed (the run says which)
delonix init --name billing-api ./Billing_API
# a manifest that names no supported framework gets the generic scaffold,
# with the reason — force a template to override
delonix init -t node
SEE ALSO:
delonix stack init · delonix vm init · delonix stack apply · delonix compose
up
delonix › initExemplosExamples
delonix initdetected go.mod → stack init --template go
created: ./Delonixfile
created: ./delonix-manifest.yaml
already exists, skipped: ./go.mod (use --force to overwrite)delonix init -t djangodelonix init --name billing-api ./Billing_APIdelonix init -t django -v 4.2 apperror[DX-1000] invalid argument: template 'django' is validated with -v 5.2,6.0,6.1; '4.2' is outside that rangedelonix stack init -t listdelonix initdelonix initwarning found docker-compose.yml — this project already runs natively with `delonix compose up`; generating a second manifest would give it two sources of truth