Sezione Librerie

La sezione Librerie ti permette di sviluppare una libreria condivisa in locale e vederla nei micro che la consumano, senza pubblicarla in un registro. Aseptic costruisce il suo artefatto e lo collega a ogni consumatore. Supporta librerie npm, Maven, Gradle e Python.

È una sezione con pattern lista + dettaglio (come Micro): sul lato, il catalogo di librerie; al centro, il dettaglio modificabile di quella selezionata.

Cosa vuol dire «collegare»

Dipende dalla tecnologia, perché ogni ecosistema risolve le sue dipendenze in un posto diverso. Non scegli tu il meccanismo: lo deduce Aseptic da cos’è la libreria.

Tecnologia	Dove finisce l’artefatto	Cosa annulla scollegare
npm	copiato sul `node_modules/<pacchetto>` del consumatore	cancella la copia e ripristina la cartella originale
Maven e Gradle	il repository locale (`~/.m2`), da cui risolvono tutti i consumatori	cancella quella versione dal repository locale (Maven la riscarica dal remoto)
Python	la ruota (`.whl`), installata nell’ambiente virtuale di ogni consumatore	la disinstalla e reinstalla la versione che c’era prima

In tutti e tre i casi è reversibile: ogni collegamento lascia un segno, e scollegare annulla solo ciò che ha messo Aseptic. Un artefatto che c’era già — una versione scaricata dal registro — non viene mai toccato.

Aggiungere una libreria

Dal pulsante di aggiunta (barra superiore) —offerto anche nello sfondo vuoto della sezione quando non ce n’è ancora nessuna—:

Aggiungi libreria — scegli la cartella del repo. Appena lo fai, Aseptic ti mostra ciò che ha riconosciuto prima di aggiungere qualsiasi cosa: la tecnologia, il nome del pacchetto, la versione e quali micro del catalogo lo dichiarano già. Se la cartella non è una libreria che sa costruire, te lo dice lì e non lascia continuare.
Importa da Git — clona il repo e la aggiunge. Qui non c’è anteprima: non c’è nulla su disco da guardare finché non si è clonato.

La tecnologia si deduce dal repo: pom.xml → Maven, build.gradle → Gradle, package.json con name → npm, pyproject.toml/setup.py → Python. Il pacchetto è il nome così come lo scriverebbe chi la consuma: il name del package.json, groupId:artifactId in JVM, il nome di distribuzione in Python.

Il dettaglio di una libreria

Identità e ricetta di build. Si salva da sola (autosave con un piccolo ritardo, come in Micro; si può disattivare in Impostazioni):

Nome e Pacchetto.
Tecnologia — quella dedotta all’aggiunta. Puoi cambiarla se ha sbagliato.

Build — il comando che costruisce l’artefatto e il percorso dell’artefatto. Se non li dichiari, si usano quelli del profilo della sua tecnologia:

Tecnologia	Build predefinita	Percorso dell’artefatto
npm	`npm run build`	`dist/<ultimo segmento del pacchetto>`
Maven	`${mvn} install -DskipTests`	`target`
Gradle	`${gradle} publishToMavenLocal -x test`	`build/libs`
Python	`python -m build --wheel`	`dist`

Consumatori — i micro che usano la libreria. Per impostazione predefinita vengono rilevati da soli leggendo chi dichiara quel pacchetto (package.json, pom.xml, build.gradle, requirements.txt, pyproject.toml); puoi fissarli a mano (id di micro separati da virgola).
Sorveglia i cambiamenti — ricostruisce e ricollega automaticamente al cambiare del codice.

${mvn} e ${gradle} vengono sostituiti dall’eseguibile del repo: il suo wrapper (mvnw, gradlew) se lo porta, quello globale altrimenti. Così la ricetta vale uguale su tutte le macchine della squadra.

Stato e azioni

Per libreria:

Azione	Cosa fa
Installare	Installa le dipendenze della libreria nel suo repo (la build lo fa da sola se mancano).
Costruire	Genera l’artefatto.
Collegare	Costruisce e mette l’artefatto dove ogni consumatore lo risolve (vedi la tabella sopra).
Scollegare	Annulla il collegamento in ogni consumatore e ripristina ciò che c’era prima.
Sorvegliare	Fa costruire + collegare a caldo a ogni cambiamento. Richiede il motore attivo.

Lo stato di ogni libreria (costruita / non costruita, collegata in N consumatori, in sorveglianza) si vede nell’elenco e nel dettaglio.

Durante la sorveglianza, Aseptic ignora ciò che scrive la build stessa — node_modules, target, build/, l’ambiente virtuale e le cache — per non entrare in un ciclo di ricostruzione senza fine.

Un avviso su Maven e Gradle

In JVM l’artefatto non vive nel repo del consumatore, ma nel tuo repository locale. Questo ha due conseguenze:

Il collegamento vale per tutti i micro insieme, che siano o meno nello scenario.
Se la tua libreria non lascia risolvere la sua versione dal repo (un pom.xml che la eredita con ${revision}, un group calcolato in uno script di Gradle), il collegamento te lo dirà. Si risolve dichiarando la versione nello YAML della libreria (stack.version).

Repository (Git)

Come in Micro, il dettaglio di una libreria include il suo Git: cambiare ramo, fare fetch e pull (--ff-only). L’accesso è di sola lettura (non fa mai push), e se ci sono modifiche non confermate, Aseptic avvisa prima di cambiare ramo o aggiornare.

Se il repo non è su disco

Se la cartella di una libreria è stata spostata, il dettaglio lo segnala e propone di rilocalizzare: scegli la nuova cartella e il percorso viene salvato.

Non invasivo

Aseptic non modifica il repo del consumatore né quello della libreria: non tocca il loro package.json, pom.xml o requirements.txt. Ciò che tocca è quello che vive fuori da Git — node_modules, il repository locale, l’ambiente virtuale — e sempre con un segno per poterlo annullare.

In npm c’è un’eccezione da tenere presente: un npm install nel consumatore sovrascrive il suo node_modules e si porta via il collegamento. Aseptic lo rileva e ricollega alla fine. Con Maven e Gradle non succede, perché l’artefatto non vive lì.

Eliminare una libreria dal catalogo non la scollega: se era collegata, scollegala prima dal dettaglio.

Dalla CLI e dal MCP

aseptic library detect/list/status/build/link/unlink/watch. Quelle di sola lettura (library_detect, library_list, library_status) sono anche disponibili come tool del MCP.

Vedi anche

Sezione Micro · Lo spazio di lavoro e .aseptic/