Come distribuire gli script nativi perl senza un overhead del modulo personalizzato?

Question

Come si può distribuire script Perl nativi (non "compilati/perl2exe/...") senza forzare gli utenti a conoscere i moduli personalizzati (non CPAN) di cui gli script hanno bisogno per funzionare?

Il problema è che gli utenti copieranno inevitabilmente lo script da qualche altra parte nel sistema e rimuoveranno lo script dal suo ambiente nativo e quindi non potrà più trovare i moduli necessari per l'esecuzione.

A volte mi sono accontentato di copiare il modulo nello script vero e proprio, ma preferirei una soluzione più pulita.

Aggiornamento: è meglio chiarire. Distribuisco un gruppo di script che capita di utilizzare moduli simili nel back-end. Gli utenti capiscono come eseguire script Perl, ma piuttosto che fare affidamento su "non spostare lo script" preferisco semplicemente consentire loro di spostare i file. Il percorso di minor resistenza.

Answer 1

Se uno script preparato per un client richiede moduli "personalizzati", è sufficiente comprimere i moduli come se si stessero tentando di caricarli su cpan. Quindi consegnare il pacchetto al client e utilizzare l'utilità cpan per installare lo script e i moduli.

Answer 2

Il modo giusto è di dire "Non farlo!" Spero che non si aspettino di spostare un file exe e che il programma continui a funzionare. Questo non è diverso.

Detto questo, ci sono un paio di alternative. Uno sta sostituendo lo script con un wrapper (ad es. Pl2bat) che conosce il percorso completo dello script reale. Un altro è usare PAR, ma ciò richiederebbe l'installazione di PAR e/o parl (da PAR :: Packer).

Answer 3

Distribuire un programma di installazione insieme allo script. Il programma di installazione dovrà essere eseguito con i privilegi di root e inserirà i moduli personalizzati nella posizione di sistema standard (/ usr/local/lib/perl5/site_perl o qualsiasi altra cosa).

Non ho provato questo, ma Module::Install sembra utile in questo senso. E 'descritto come un:

autonomo, estensibile Perl modulo installatore

Answer 4

Sarebbe davvero bello se si potrebbe utilizzare un fascio NeXTSTEP style application. Dato che probabilmente non stai sviluppando per una piattaforma che usa i bundle, dovrai farlo.

Inserire tutti i file di supporto in una posizione nota e puntare il file eseguibile in tali file per accedere alle impostazioni e alle librerie. Il modo più semplice per farlo è con un semplice programma di installazione.

Ad esempio, con un'applicazione chiamata foo, mettere tutti i file necessari in /opt/xlyd_apps/foo, biblioteche /opt/xlyd_apps/foo/lib, configurazione /opt/xlyd_apps/foo/etc, e così via. Metti l'eseguibile in /opt/xlyd_apps/foo/bin.

La cosa importante è quello di assicurarsi l'eseguibile sa di dover cercare in /opt/xlyd_apps/foo per tutti i suoi chicche, per cui se il cliente/cliente spostare lo script foo in una nuova posizione l'installazione funziona ancora.

Quindi, anche se non è possibile rendere l'intero oggetto autonomo e ricollocabile, è possibile rendere rilocabile lo script di chiamata effettivo.

Answer 5

Come variante del "mettere i moduli in un unico luogo e rendere le applicazioni a conoscenza di esso", che funziona anche su più computer e reti, forse si dovrebbe verificare PAR::Repository rispettivamente PAR::Repository::Client. Dovresti solo fornire un singolo eseguibile del client binario che si connette al repository (tramite file system o https) ed esegue qualsiasi numero arbitrario di programmi (utilizzando un insieme arbitrario di moduli) fornito dal repository richiesto dall'utente.

Se ci sono molti utenti, questo ha anche un vantaggio per la manutenzione: basta aggiornare il software fornito dal repository e gli utenti inizieranno a utilizzare il codice aggiornato per il loro sistema al successivo avvio dei programmi.

Answer 6

In realtà ho trovato la mia soluzione e sono curioso di sapere che tipo di ricezione avrà.

Ho scritto uno script che legge uno script perl e cerca istruzioni "use/require". Dopo averli trovati controlla se il modulo fa parte della libreria standard (guarda il percorso del modulo per /perl5/\d+.\d+[\d.]+/) e poi riscrive la riga use/require in due modi diversi a seconda di utilizzo.

Se richiedono è trovato:

{ 
    ... inline the entire module here... 
} 

Se uso si trova:

BEGIN { 
    ... inline the entire module here... 
} 

Se uso ha importazioni, seguono immediatamente sopra con:

BEGIN { import Module ...imports seen... } 

Capisco che questo non funzioni con i moduli che usano XS, ma mi andava bene con questo. Per lo più ho bisogno di supportare solo moduli Perl puri.