La cosa che non mi piace molto di avere un unico repo in github con 30 sotto progetti e’ il mischiarsi di issues/PRs e CI collegata all’intero progetto. Entrambe i problemi possono essere risolti con un singolo monorepo, quindi immagino si tratti di una preferenza personale alla fine,

link interessante. neanche io sono un fan di monorepo, mi do un’occhiata cosa dicono questi ragazzi lo stesso pero’ :)

mi sembra un buon approccio, queste cose sono sempre un po' spaventevoli quando le guardo (yet another framework) ma qui praticamente vedo solo convenzioni e tools attorno

bel link grazie Renzo

qualcuno mi puo’ spiegare il perche’ di usare interface.clj e non usare direttamente core.clj ?

probabilmente perche’ il nome e’ piu’ esplicito riguardo all’uso che se ne vuole fare, rispetto a “core” che potrebbe contenere qualunque cosa

ah tipo come fare un subset delle funzioni di core che si possono usare? :thinking_face:

perche’ poi in interface si usano proprio le funzioni di core

non necessariamente, probabilmente interface potrebbe dipendere da altri namespace e core potrebbe essere relegato a contenere “main”

giusto giusto 🙂

la definizione della spec in genere la metto nel file che si riferisce a quel concetto (e ha le funzioni che operano su quello). Le spec per le funzioni le definisco inline nelle funzioni utilizzando guardrails (my 2c)

eh non mi piace cambiare la sintassi di defn...e' troppo invasivo (IMHO)