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 é uma função pura sobre os nomes de ficheiro presentes, ordenada do mais específico para o mais genérico (um projecto Django também tem .py, e um Next.js também tem package.json — a regra mais larga não pode ganhar só por ter sido verificada primeiro). 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.

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:
      --l18n <en|pt>
          Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand

  -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

  -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`
  delonix init -t odoo -v 18.0

  # ...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

  # ...or a Go toolchain version — this template has no framework to pin
  delonix init -t go -v 1.22 myapp

SEE ALSO:
  delonix stack init · delonix vm init · delonix stack apply · delonix compose
  up

  delonix › init

ExemplosExamples

delonix init

detected go.mod → stack init --template go
  created: ./Delonixfile
  created: ./delonix-manifest.yaml
  already exists, skipped: ./go.mod  (use --force to overwrite)

delonix init -t django

delonix stack init -t list

delonix init

delonix init

warning found docker-compose.yml — this project already runs natively with `delonix compose up`; generating a second manifest would give it two sources of truth