Mi sto appassionando sempre di più a Catalyst, e finalmente lo utilizzerò per lavoro almeno in un paio di progetti. Il framework ha tutte le carte in regola per diventare un killer, visto che ormai l'API è abbastanza stabile, i principali bug sono stati limati, ed iniziano ad apparire su CPAN plugin in grande quantità.

Uno dei punti di forza del framework è il fatto che esso si basa fortemente su CPAN: installare Catalyst vuol dire installare oltre 60 moduli. Questo è ciò che io chiamo "riutilizzare il codice".

Uno dei punti di debolezza del framework è il fatto che esso si basa fortemente su CPAN: installare Catalyst vuol dire installare oltre 60 moduli. Questo è ciò che io chiamo un vero incubo.

E` vero che, servendosi del modulo CPAN, l'operazione può risultare piuttosto semplice, e ridursi ad un:

cpan -i Task::Catalyst

che installa il framework ed i moduli più comuni (tra cui Prototype, Session, DBIx::Class, ...).

Tuttavia molti vorrebbero tenere un po' d'ordine nel proprio sistema, ed utilizzare il proprio package manager di sistema (Apt, Portage, ...) per gestirne installazione ed aggiornamento. Inoltre, dal punto di vista di chi deve provare Catalyst per la prima volta, sapere che può installarlo direttamente col suo package manager di sistema potrebbe essere un fattore che determina se lo proverà oppure volgerà prima lo sguardo verso altre soluzioni come Ruby-On-Rails.

Ho effettuato alcune prove con Gentoo, la distribuzione che utilizzo, ed in effetti la situazione non è granché rosea. Esiste il programma g-cpan che automatizza la pacchettizzazione e l'installazione dei moduli CPAN non presenti in Portage (e nessuno di quelli relativi a Catalyst lo è). Il software non è tuttavia esente da problemi - in particolare se viene utilizzato CPANPLUS - ed un semplice:

g-cpan -i Task::Catalyst

generalmente non funziona. Un'installazione più "all'osso" con:

g-cpan -i Catalyst

di solito va a buon fine, anche se non sempre in maniera propriamente liscia. A volte alcune delle dipendenze vengono installate da CPAN senza venire "pacchettizzate", e l'upgrade tende a dare errori.

La via da percorrere per fornire un'installazione facile, sicura, e facilmente aggiornabile, è quella di creare gli ebuild sotto dev-perl per tutti i moduli CPAN richiesti. Mi sono cimentato, e sono persino a buon punto, anche se mi sto scontrando con vari inconvenienti relativi agli ebuild già presenti nel repository ufficiale Gentoo: dipendenze sbagliate, pacchetti marcati solo x86 e non amd64/altre_architetture, versioni vecchie.

Segnalando i problemi su bugs.gentoo.org dovrei venire a capo della situazione in tempi relativamente brevi. Tuttavia, anche a quel punto,un eventuale utente dovrà scaricarsi i miei ebuild, copiarli nella sua directory di overlay, ed effettuare l'installazione. Ci sarà da lavorare con la Perl Herd di Gentoo per tentare di inserire tutto nel repository ufficiale, e prima che 60 moduli possano venir dichiarati stabili ne passerà di acqua sotto i ponti.

In conclusione, il sentiero sembra percorribile, ma l'impressione è quella che siamo ancora piuttosto lontani dal momento in cui qualsiasi utilizzatore Gentoo potrà scrivere:

emerge catalystframework

e ritorvarsi un'installazione di Catalyst completa e funzionante, esattamente come può fare ora con:

emerge rails

per ottenere Ruby-On-Rails. In realtà l'utente deve comunque smanettare 2 con il file package.keywords in quando al momento rails ancora è ~arch e quindi non ancora dichiarato stabile; ma un conto è aggiungere una riga in package.keywords, un altro sarà aggiungerne 60 se e quando i moduli di Catalyst raggiungeranno il repository ufficiale Gentoo.

Beh, c'è anche la parte buona: in tutto questo tempo Catalyst avrà il tempo di maturare. ;-)

Inviato da arthas il 01.01.06 23:25
Ti è piaciuto questo articolo? Iscriviti al feed!