A árvore inteira, e os conflitos dela

Vários pacotes num repositório: quem depende de quê, e duas faixas incompatíveis do mesmo terceiro — achadas antes de instalar.

Cada pacote tem o seu forge.toml. A única forma de saber se dois deles pedem faixas incompatíveis do mesmo terceiro era instalar os dois e esperar o erro — que aparece no dia da instalação, na máquina de quem consome.

dataforge workspace              # a arvore daqui para baixo
dataforge workspace packages     # so uma pasta
dataforge workspace --json       # para o CI ler
dataforge ws                     # o mesmo comando

── 25 pacote(s) em packages ──
  aleatorio            0.1.0      0 dep(s)  aleatorio/forge.toml
  validador            0.1.0      1 dep(s)  validador/forge.toml
  …

  nenhum conflito de faixa entre os pacotes

Conflito é erro, e não aviso#

O comando sai com 2 quando duas faixas não se cruzam. É a mesma decisão que o resolvedor de dependências já tomava: instalar duas cópias do mesmo pacote em versões diferentes gera bug irreproduzível.

  CONFLITOS:
   terceiro
      um pede 1.0.0
      dois pede 2.0.0

Ele não inventa conflito#

Sem uma lista das versões publicadas não há como decidir por enumeração. Então a pergunta é feita sobre os pinos exatos: se um lado exige ==X e o outro recusa o X, o conflito está provado. Fora disso, cala.

É a mesma prudência do analisador estático: um falso conflito faria o comando ser ignorado, e aí ele não serviria para o caso verdadeiro.

E ele não instala#

Ler e relatar. Instalar a árvore inteira a partir de um comando que a pessoa rodou para "ver o que tem" seria mexer em disco sem ser pedido — quem quer instalar chama dataforge install, em cada pacote.

As pastas que não são pacote do projeto ficam fora da varredura: forge_modules, node_modules, dist, out, .venv e as que começam com ponto.