Leggendo que­sto arti­colo che defi­ni­sce le pra­ti­che per quello che viene defi­nito seman­tic ver­sio­ning, mi è venuto in mente che tcl sup­porta diret­ta­mente a livello di lin­guag­gio il con­trollo della ver­sione dei pac­kage caricati.

Package require e i moduli in soccorso

L’uso è banale: basta spe­ci­fi­care la ver­sione che si vuole usare, con la pos­si­bi­lità di essere restrit­tivi fino al punto di cari­care una ver­sione spe­ci­fica e non una sem­pli­ce­mente compatibile.

La cosa mi è stata molto utile durante lo svi­luppo di alcuni moduli. Come spesso suc­cede, man mano che le idee diven­tano più chiare, le prime ver­sioni sono quasi sem­pre da rifare; tut­ta­via era spesso impos­si­bile modi­fi­care subito tutti gli script che uti­liz­za­vano il modulo rivi­sto per far­gli cari­care subito la nuova ver­sione. È bastato quindi spe­ci­fi­care la ver­sione cor­retta nel codice che usava quel modulo.

Bisogna anche notare che le due ver­sioni dei moduli pos­sono con­vi­vere nel file system tran­quil­la­mente l‘una accanto all’altra gra­zie all’infra­strut­tura dei moduli.

Non è comun­que pos­si­bile cari­care due ver­sioni diverse all’interno dello stesso inter­prete ¹ ma visto che in Tcl è faci­lis­simo creare inter­preti aggiun­tivi, il pro­blema potrebbe essere miti­ga­bile:

% 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 sap­pia, non mi risulta che né Perl né Python né Ruby pos­sie­dano que­sta caratteristica.

Qualcuno ha infor­ma­zioni più pre­cise su que­sti o altri linguaggi?

Alcuni post sugli Starkit, una moda­lità di distri­bu­zione di appli­ca­tivi auto­con­te­nuti in Tcl:

• Sorprese di fine anno: il casus belli che mi ha por­tato ad appro­fon­dire que­sta soluzione;
• Anatomia di uno Starkit: com’è fatto, come funziona;
• Gli Starpack: usando gli Starkit come punto di par­tenza, creiamo delle distri­bu­zioni com­ple­ta­mente auto–contenute;
• Starkits: ultimi det­ta­gli: ana­lisi di alcune fea­tu­res avanzate.

Nel chiu­dere que­sta pano­ra­mica sugli Starkit, riporto qual­che infor­ma­zione in più sugli aspetti che mi sem­brano meri­tino un qual­che approfondimento.

VFS: Virtual File System

Una delle carat­te­ri­sti­che più inte­res­santi può essere usata anche al di fuori degli Starkit ed è il Virtual File System. Ricorda un po’ il clas­sico approc­cio Unix, dove uno dei modi pre­fe­riti di ren­dere dispo­ni­bili degli oggetti al sistema ope­ra­tivo è quello di rap­pre­sen­tarli come file system.

Allo stesso modo, con i VFS, è pos­si­bile “mon­tare” un sito ftp remoto, come un data­base Metakit, addi­rit­tura un name­space, come in que­sto esem­pio, dove leg­giamo il con­te­nuto della pro­ce­dura 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 otte­nere lo stesso risul­tato, 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 modi­fi­cati al run­time e in tran­quil­lità, visto che Metakit è transazionale.

In que­sto modo diventa pos­si­bile usare gli Starkit un po’ come con Java Web Start, dove lo Starkit distri­buito si inca­ri­cherà esso stesso di sca­ri­care e instal­lare i com­po­nenti neces­sari diret­ta­mente al suo interno.

Adesso che abbiamo visto come sono costruiti gli StarKit, è sem­plice esten­dere il discorso agli StarPacks.

Premesse

Prima di tutto dob­biamo ricor­dare che uno StarKit può con­te­nere delle com­po­nenti com­pi­late. In virtù di que­sto fatto, pos­siamo costruire un StarKit che con­terrà al suo interno l’interprete spe­ci­fico per una data piat­ta­forma. In pra­tica, la dif­fe­renza fra uno StarKit e uno StarPack sta nel fatto che quest’ultimo usa un ese­gui­bile com­pi­lato per avviarsi e include tutte le libre­rie nor­mal­mente incluse con TclKit.

Pregi e difetti

Le limi­ta­zioni più impor­tanti di uno StarPack sono:

1. dato che usiamo dei com­pi­lati, ogni StarPack sarà spe­ci­fico per un dato sistema operativo;
2. gli StarPack non pos­sono auto–modificarsi ¹.

La con­tro­par­tita è un sistema di distri­bu­zione com­ple­ta­mente auto–contenuto, senza alcuna instal­la­zione aggiuntiva.

La crea­zione di uno StarPack è molto simile a quella di uno StarKit: l’unica dif­fe­renza è che nel primo caso dovremo spe­ci­fi­care il run­time da asso­ciare al pro­dotto finito.

È inte­res­sante notare che gli stessi TclKit sono creati come StarPack, StarPack che non hanno codice appli­ca­tivo ma solo l’interprete e libre­rie neces­sa­rie ²

Una defi­ni­zione

Uno StarKit è un cri­te­rio per impac­chet­tare tutte le risorse neces­sa­rie ad un’applicazione in modo auto–contenuto, che non neces­sita di alcuna instal­la­zione e portabile.

In cosa dif­fe­ri­sce uno StarKit?

Non è un’idea nuova, pen­siamo per esem­pio 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 pen­sato per essere com­ple­ta­mente indi­pen­dente, tant’è vero che è pos­si­bile indi­care nel MANIFEST.MF dei para­me­tri per il clas­spath, anche se non fun­ziona molto bene, anzi. Lo stesso può essere detto, grosso modo, anche per for­mati come war, ear e com­pa­gnia bella.

Se tra­la­sciamo la que­stione dell’auto–contenimento, il tratto distin­tivo di uno StarKit è l’uso di un file system vir­tuale, che con­sente all’applicazione di com­por­tarsi esat­ta­mente come se fosse lan­ciata da una ver­sione “spac­chet­tata”. All’avvio, que­sto file system viene infatti mon­tato in modo che appaia dal punto di vista dell’applicazione come una nor­male directory.

Creare uno StarKit con sdx

Uno StarKit viene creato con… un altro StarKit, chia­mato StarKit Developer eXten­sion (sdx), a cui pas­se­remo la nostra appli­ca­zione da impac­chet­tare. In ogni caso la strut­tura risul­tante 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, men­tre in main.tcl viene inse­rito il codice (gene­rato da sdx) neces­sa­rio all’avvio dell’applicazione:

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

La prime due righe cari­cano il modulo dello star­kit, ini­zia­liz­zando il file system vir­tuale e con­fi­gu­rando la varia­bile auto_path; la terza riga causa il cari­ca­mento di myKit.tcl e l’avvio vero e pro­prio dell’applicazione.

La pros­sima volta par­le­remo degli StarPack.

“Non si potrebbe fare…?”

Come se non bastasse il lavoro di rifa­ci­mento, è arri­vata sulla scri­va­nia la richie­sta di una ver­sione che:

1. possa essere usata in assenza di connettività;
2. non richieda alcuna pro­ce­dura d’installazione;
3. sia mul­ti­piat­ta­forma;
4. sia ese­gui­bile diret­ta­mente da una chiave USB.

Insomma, non pro­prio un qual­cosa da fare nei rita­gli di tempo!

Cosa usare?

All’inizio avevo pen­sato ad una qual­che appli­ca­zione in Java, usando Swing o SWT ma non ho pra­ti­ca­mente nes­suna fami­lia­rità con appli­ca­zioni desk­top di quel tipo; inol­tre non è affatto scon­tato che Java sia sem­pre installata.

Sul lato .Net, cono­sco qual­cosa di più ma non ho idea se sia fat­ti­bile uno svi­luppo multipiattaforma.

“The sim­plest thing…”

Poi mi è venuto in mente che avrei potuto rispar­miare un bel po’ di lavoro usando una ver­sione rivi­si­tata di quella su web, con la parte ser­ver che gira diret­ta­mente sul com­pu­ter dell’utente. Fattibilissimo, certo, ma non pro­prio una cosa che non richiede alcuna installazione

Infine, credo di aver tro­vato una solu­zione in Tcl, tra­mite i cosid­detti StarKit e StarPack: un colos­sale (ma leg­ge­ris­simo, in MB) uovo di colombo.

In poche parole, uno StartKit con­sente di impac­chet­tare un’intera appli­ca­zione in una spe­cie di disco imma­gine. Questo disco imma­gine con­tiene anche tutti i file ausi­liari, binari o meno, anche per diverse piattaforme.

Fin qui niente di par­ti­co­lare. In fondo, con l’avvento delle mac­chine vir­tuali è diven­tata prassi comune distri­buire diret­ta­mente dei dischi imma­gine. C’è però da supe­rare l’ostacolo dell’installazione, visto che per ese­guire uno StarKit serve comun­que un inter­prete Tcl più una serie di librerie.

E qui entrano in scena gli StarPack, che accor­pano uno StarKit e l’interprete in unico file, con­fi­gu­rato per par­tire con un dop­pio click. Il peso? Pochi MB!

Nei pros­simi giorni vedremo un po’ più in det­ta­glio come fun­ziona que­sta tecnologia.

Life goes on

Nel frat­tempo, sul fronte del refac­to­ring, ho ter­mi­nato l’accorpamento di tutto l’SQL. Adesso dovremo comin­ciare a tagliare i ponti con le sezioni che si appog­giano a Joomla.

PS · Va pre­ci­sato che con l’arrivo ormai pros­simo dell’HTML 5, diven­terà con­ce­pi­bile pen­sare a solu­zioni che pos­sano girare in com­pleta auto­no­mia, senza alcuna con­nes­sione. Tuttavia, il sup­porto da parte di Explorer è ancora incompleto.