Leggendo questo articolo che definisce le pratiche per quello che viene definito semantic versioning, mi è venuto in mente che tcl supporta direttamente a livello di linguaggio il controllo della versione dei package caricati.

Package require e i moduli in soccorso

L’uso è banale: basta specificare la versione che si vuole usare, con la pos­sibilità di essere restrittivi fino al punto di caricare una versione specifica e non una semplicemente compatibile.

La cosa mi è stata molto utile durante lo sviluppo di alcuni moduli. Come spesso succede, man mano che le idee diventano più chiare, le prime versioni sono quasi sempre da rifare; tuttavia era spesso impos­sibile modificare subito tutti gli script che utilizzavano il modulo rivisto per fargli caricare subito la nuova versione. È bastato quindi specificare la versione corretta nel codice che usava quel modulo.

Bisogna anche notare che le due versioni dei moduli pos­sono convivere nel file system tranquillamente l‘una accanto all’altra grazie all’infrastruttura dei moduli.

Non è comunque pos­sibile caricare due versioni diverse all’interno dello stesso interprete ¹ ma visto che in Tcl è facilis­simo creare interpreti aggiuntivi, il problema potrebbe essere mitigabile:

% set slave1 [interp create]
interp0
% set slave2 [interp create]
interp1
% $slave1 eval {source a.tcl}
% $slave1 eval {source a2.tcl}
conflicting versions provided
for package "a": 1.0, then 1.2.0
# a.tcl e a2.tcl contengono due
# versioni dello stesso package
% $slave2 eval {source a2.tcl}

E gli altri?

Che io sappia, non mi risulta che né Perl né Python né Ruby pos­siedano questa caratteristica.

Qualcuno ha informazioni più pre­cise su questi o altri linguaggi?

Alcuni post sugli Starkit, una modalità di distribuzione di applicativi autocontenuti in Tcl:

• Sorprese di fine anno: il casus belli che mi ha portato ad approfondire questa soluzione;
• Anatomia di uno Starkit: com’è fatto, come funziona;
• Gli Starpack: usando gli Starkit come punto di partenza, creiamo delle distribuzioni completamente auto–contenute;
• Starkits: ultimi dettagli: analisi di alcune features avanzate.

Nel chiudere questa panoramica sugli Starkit, riporto qualche informazione in più sugli aspetti che mi sembrano meritino un qualche approfondimento.

VFS: Virtual File System

Una delle caratteristiche più interes­santi può essere usata anche al di fuori degli Starkit ed è il Virtual File System. Ricorda un po’ il clas­sico approccio Unix, dove uno dei modi pre­feriti di rendere disponibili degli oggetti al sistema operativo è quello di rappresentarli come file system.

Allo stesso modo, con i VFS, è pos­sibile “montare” un sito ftp remoto, come un database Metakit, addirittura un namespace, come in questo esempio, dove leggiamo il contenuto della procedura unknown:

package require vfs::ns
vfs::ns::Mount :: ::
cd ::
set f [open "unknown" r]
set proc_definition [read $f]
close $f

Ci sono anche altri modi di ottenere lo stesso risultato, a volte anche più adatti, ma l’uso dei comandi di I/O può essere a volte il sistema giusto.

StarKits auto–aggiornanti

Gli Starkit (ma non gli Starpack) pos­sono essere modificati al runtime e in tranquillità, visto che Metakit è transazionale.

In questo modo diventa pos­sibile usare gli Starkit un po’ come con Java Web Start, dove lo Starkit distribuito si incaricherà esso stesso di scaricare e installare i componenti neces­sari direttamente al suo interno.

Adesso che abbiamo visto come sono costruiti gli StarKit, è semplice estendere il discorso agli StarPacks.

Premesse

Prima di tutto dobbiamo ricordare che uno StarKit può contenere delle componenti compilate. In virtù di questo fatto, pos­siamo costruire un StarKit che conterrà al suo interno l’interprete specifico per una data piattaforma. In pratica, la differenza fra uno StarKit e uno StarPack sta nel fatto che quest’ultimo usa un eseguibile compilato per avviarsi e include tutte le librerie normalmente incluse con TclKit.

Pregi e difetti

Le limitazioni più importanti di uno StarPack sono:

1. dato che usiamo dei compilati, ogni StarPack sarà specifico per un dato sistema operativo;
2. gli StarPack non pos­sono auto–modificarsi ¹.

La contro­partita è un sistema di distribuzione completamente auto–contenuto, senza alcuna installazione aggiuntiva.

La creazione di uno StarPack è molto simile a quella di uno StarKit: l’unica differenza è che nel primo caso dovremo specificare il runtime da associare al prodotto finito.

È interes­sante notare che gli stessi TclKit sono creati come StarPack, StarPack che non hanno codice applicativo ma solo l’interprete e librerie neces­sarie ²

Una definizione

Uno StarKit è un criterio per impacchettare tutte le risorse neces­sarie ad un’applicazione in modo auto–contenuto, che non neces­sita di alcuna installazione e portabile.

In cosa differisce uno StarKit?

Non è un’idea nuova, pensiamo per esempio ai Jar nel mondo Java, che sono degli zip con un file – il MANIFEST.MF – che indica la classe per avviare l’applicazione. Tuttavia, un Jar non è stato pensato per essere completamente indipendente, tant’è vero che è pos­sibile indicare nel MANIFEST.MF dei para­metri per il clas­spath, anche se non funziona molto bene, anzi. Lo stesso può essere detto, grosso modo, anche per formati come war, ear e compagnia bella.

Se tralasciamo la questione dell’auto–contenimento, il tratto distintivo di uno StarKit è l’uso di un file system virtuale, che consente all’applicazione di comportarsi esattamente come se fosse lanciata da una versione “spacchettata”. All’avvio, questo file system viene infatti montato in modo che appaia dal punto di vista dell’applicazione come una normale directory.

Creare uno StarKit con sdx

Uno StarKit viene creato con… un altro StarKit, chiamato StarKit Developer eXtension (sdx), a cui pas­seremo la nostra applicazione da impacchettare. In ogni caso la struttura risultante sarà una cosa del genere:

• myKit.vfs
  • main.tcl
  • lib
  • app-myKit
    • myKit.tcl
    • pkgIndex.tcl

La sequenza di avvio

Ovvero, tutta l’applicazione viene messa sotto lib, mentre in main.tcl viene inserito il codice (generato da sdx) neces­sario all’avvio dell’applicazione:

 package require starkit
 starkit::startup
 package require app-myKit

La prime due righe caricano il modulo dello starkit, inizializzando il file system virtuale e configurando la variabile auto_path; la terza riga causa il caricamento di myKit.tcl e l’avvio vero e proprio dell’applicazione.

La pros­sima volta parleremo degli StarPack.

“Non si potrebbe fare…?”

Come se non bastasse il lavoro di rifacimento, è arrivata sulla scrivania la richiesta di una versione che:

1. possa essere usata in assenza di connettività;
2. non richieda alcuna procedura d’installazione;
3. sia multipiattaforma;
4. sia eseguibile direttamente da una chiave USB.

Insomma, non proprio un qualcosa da fare nei ritagli di tempo!

Cosa usare?

All’inizio avevo pensato ad una qualche applicazione in Java, usando Swing o SWT ma non ho praticamente nes­suna familiarità con applicazioni desktop di quel tipo; inoltre non è affatto scontato che Java sia sempre installata.

Sul lato .Net, conosco qualcosa di più ma non ho idea se sia fattibile uno sviluppo multipiattaforma.

“The simplest thing…”

Poi mi è venuto in mente che avrei potuto risparmiare un bel po’ di lavoro usando una versione rivisitata di quella su web, con la parte server che gira direttamente sul computer dell’utente. Fattibilissimo, certo, ma non proprio una cosa che non richiede alcuna installazione

Infine, credo di aver trovato una soluzione in Tcl, tramite i cosiddetti StarKit e StarPack: un colos­sale (ma leggeris­simo, in MB) uovo di colombo.

In poche parole, uno StartKit consente di impacchettare un’intera applicazione in una specie di disco immagine. Questo disco immagine contiene anche tutti i file ausiliari, binari o meno, anche per diverse piattaforme.

Fin qui niente di particolare. In fondo, con l’avvento delle macchine virtuali è diventata prassi comune distribuire direttamente dei dischi immagine. C’è però da superare l’ostacolo dell’installazione, visto che per eseguire uno StarKit serve comunque un interprete Tcl più una serie di librerie.

E qui entrano in scena gli StarPack, che accorpano uno StarKit e l’interprete in unico file, configurato per partire con un doppio click. Il peso? Pochi MB!

Nei pros­simi giorni vedremo un po’ più in dettaglio come funziona questa tecnologia.

Life goes on

Nel frattempo, sul fronte del refactoring, ho terminato l’accorpamento di tutto l’SQL. Adesso dovremo cominciare a tagliare i ponti con le sezioni che si appoggiano a Joomla.

PS · Va pre­cisato che con l’arrivo ormai pros­simo dell’HTML 5, diventerà concepibile pensare a soluzioni che pos­sano girare in completa autonomia, senza alcuna connes­sione. Tuttavia, il supporto da parte di Explorer è ancora incompleto.