Come utilizzare i moduli beta Perl dagli script Perl beta?

Question

Se il mio codice Perl ha una posizione codice di produzione e la posizione codice "beta" (ad esempio, la produzione di Perl ci codificare in /usr/code/scripts, BETA codice Perl è in /usr/code/beta/scripts; biblioteche produzione Perl sono in /usr/code/lib/perl e le versioni beta di queste librerie sono in /usr/code/beta/lib/perl, c'è un modo facile per me per raggiungere un tale configurazione

I requisiti esatti sono:?.

• Il codice deve essere lo stesso per la produzione e la posizione BETA

  Per chiarire, per promuovere qualsiasi codice (libreria o script) da BETA alla produzione, l'unica cosa che deve accadere è letteralmente il comando cp da BETA a prod posizione - sia il nome del file che il contenuto del file devono rimanere identici.

• versioni beta di script devono chiamare altri script BETA e librerie BETA (se esiste) o le librerie di produzione (se non esistono le biblioteche BETA)

• I percorsi di codice deve essere lo stesso tra beta e di produzione con la eccezione della directory di base (/usr/code/ vs /usr/code/beta/)

• Gli script deve essere sotto la stessa directory di base ma possono essere nelle sue sottodirectory a livello profondità arbitraria (ciò preclude la classica soluzione use lib "$FindBin::Bin/../lib" dalla sezione 31.13. utilizzare lib di "Programming Perl")

presenterò come abbiamo risolto il problema come una risposta a questa domanda, ma mi piacerebbe sapere se c'è un modo migliore.

Answer 1

la nostra soluzione è la seguente:

• dispone di una libreria (chiamiamolo BetaOrProd.pm)

  • La biblioteca deve essere inclusa tramite "use BetaOrProd;" in ogni script
  • La libreria DEVE essere la primissima istruzione use in ogni script dopo "use strict;" pragma (e "usa avvisi" se lo usiamo). Compreso prima dei blocchi BEGIN.
  • La biblioteca ha un blocco BEGIN, che contiene la maggior parte della logica
  • Che BEGIN blocco nei controlli della biblioteca percorso della directory del programma (in base al largo di $ 0 al percorso assoluto applicato)
  • Se il percorso della directory inizia con /usr/code/beta, il programma è considerato per l'esecuzione in posizione BETA, il resto della produzione
  • in entrambi i casi, /usr/local/lib/perl è un-spostata all'inizio del @INC lista
  • Se la posizione BETA, /usr/code/beta/lib/perl è un-spostata all'inizio del @INC lista dopo.
  • Se posizione BETA, una variabile speciale $ isBETA (accessibile da un metodo accessor esportato da BetaOrProd.pm) è impostata su "BETA".

• Ogni volta che uno script/biblioteca ha bisogno di chiamare un altro script, il percorso dello script chiamato è calcolato sulla base detto di accesso alla variabile $ isBETA esportati da BetaOrProd.pm

• Ogni volta che una biblioteca Perl esigenze a essere richiesto o utilizzato, non è necessaria alcuna logica speciale - il @INC modificato da BetaOrProd.pm si occupa di sapere da dove i moduli devono essere importati. Se il modulo è presente nella posizione BETA, la libreria dalla posizione BETA verrà utilizzata dallo script BETA, altrimenti la libreria dalla posizione prod.

I principali svantaggi di questo approccio sono:

1. Requisito che ogni script must have "use BetaOrProd;" come il primo use affermazione in tutti gli script dopo "use strict;" pragma.

   Mitigato dal fatto che la nostra azienda richiede che ogni pezzo di codice distribuito superi il validatore automatico, che può verificare questo requisito.

2. Impossibile test BETA BetaOrProd.pm tramite /usr/code/beta/lib/perl. D'uh.

   Mitigato per unità molto approfondita e test di integrazione della biblioteca

Answer 2

ho dovuto utilizzare una configurazione simile. Il modulo è stato chiamato dopo il nome del progetto, tuttavia, e potrebbe svolgere altri compiti: caricare alcune variabili di configurazione specifiche dell'ambiente (posizioni di dati, credenziali per i database dev/prod, ad esempio), elaborare alcuni argomenti della riga di comando e impostare alcune altre variabili che sono stati utili per la maggior parte degli script nel progetto (la data corrente in formato AAAAMMGG, se il mercato azionario è stato aperto, ecc)

Answer 3

rivolgo questo con FindBin:

use FindBin; 
use lib "$FindBin::Bin/../lib"; 

Oppure, se la modalità di contaminazione è attiva:

use FindBin; 
use lib ("$FindBin::Bin/../lib" =~ m[^(/.*)])[0]; 

Poiché non dipende da alcun percorso noto o fisso, consente di creare il numero di set indipendenti del codice su una singola macchina, semplicemente creando una nuova copia della directory del progetto.

Conservo copie complete di tutti i moduli di progetto in ciascuna immagine di sviluppo del progetto, ma sembra che tu non sia e preferisci affidarti alla copia beta che ricade sui moduli della copia live; un use lib /path/to/live/bin precedente allo s in grado di gestirlo, oppure si potrebbe semplicemente collegare /path/to/live/bin in una delle directory su @INC in modo che sia sempre disponibile immediatamente.

Se le versioni live e beta verranno eseguite da diversi account, potrebbe anche valere la pena esaminare local::lib, ma questo non sembra essere esattamente quello a cui è destinato.

UPDATE: Questo non funziona se gli script stessi possono vivere in più sottodirectory di una determinata directory, ma funziona diversamente.