Come faccio a usare moduli Perl beta da beta script Perl?

Question

Se il mio codice Perl ha una posizione codice di produzione e "beta" posizione del codice (Ad esempio la produzione di Perl ci codificare in /usr/code/scripts, BETA codice Perl è in /usr/code/beta/scripts; produzione librerie Perl sono nelle versioni /usr/code/lib/perl e 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 in produzione e BETA posizione.

  Per chiarire, per promuovere qualsiasi codice (biblioteca o lo script) da BETA alla produzione, l'unica cosa che deve accadere è il comando cp letteralmente emissione da BETA per spingere il percorso - sia il nome del file e file di contenuto deve rimanere identico .

• Le versioni beta di script devono chiamare altri script e librerie BETA 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 l'eccezione della directory di base (/usr/code/ vs /usr/code/beta/)

• Gli script devono essere tutti sotto lo stesso directory di base ma possono essere nelle sue sottodirectory a livello di profondità arbitraria (questo preclude la soluzione use lib "$FindBin::Bin/../lib" classico sezione 31.13. utilizzare lib di "Programming Perl" )

I 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:

• Avere una libreria (chiamiamolo BetaOrProd.pm)

  • La biblioteca deve essere inclusa tramite "use BetaOrProd;" in ogni script
  • La biblioteca deve essere la prima istruzione use in ogni script dopo "use strict;" pragma (e "Usa avvertimenti", se usiamo quello). Anche prima eventuali blocchi BEGIN.
  • La biblioteca ha un blocco BEGIN che contiene la maggior parte della logica
  • che bloccano BEGIN 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 si ritiene che l'esecuzione in posizione BETA, il resto della produzione
  • In entrambi i casi, è un-/usr/local/lib/perl spostato l'inizio della lista @INC
  • Se la posizione BETA, /usr/code/beta/lib/perl è un-spostata verso l'inizio della lista @INC dopo.
  • Se la posizione BETA, una variabile speciale $ isBETA (accessibile con un metodo di accesso esportato da BetaOrProd.pm) è impostato su "beta".

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

• Ogni volta che una libreria Perl ha bisogno di essere richiesto o usato, è necessario alcuna logica speciale - il @INC modificato da BetaOrProd.pm si prende cura di sapere dove i moduli devono essere importati da. Se il modulo è presente in posizione BETA, quindi la libreria dalla posizione BETA sarà utilizzato dallo script BETA, altrimenti la libreria dalla posizione prod.

I principali inconvenienti di questo approccio sono:

1. Requisito che ogni script deve avere "use BetaOrProd;", come la prima dichiarazione use in tutti gli script dopo "use strict;" pragma.

   mitigato dal fatto che la nostra azienda richiede ogni pezzo schierato di codice per passare validatore automatizzato, in grado di verificare la presenza di questo requisito.

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

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

Answer 2

mi rivolgo a questo con FindBin :

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

In alternativa, se la modalità di contaminazione è attivo:

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

Poiché questo non dipende da eventuali percorsi conosciuti o fissi, permette a molti gruppi indipendenti di codice su una singola macchina come piace, semplicemente creando una nuova copia della directory progetto.

Io sostengo copie complete di tutti i moduli del progetto ogni immagine lo sviluppo del progetto in, ma suona come non si e invece affidamento sulla copia beta ricadere ai moduli della copia dal vivo; un use lib /path/to/live/bin prima delle use libs sopra avrebbe gestito che, o si può semplicemente collegare /path/to/live/bin in una delle directory su @INC in modo che sarà sempre disponibile immediatamente.

Se le versioni live e beta verranno eseguiti da diversi account, città :: lib può anche essere la pena di guardare, ma questo in realtà non sembra essere quello che è destinato.

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

Answer 3

Ho dovuto usare una configurazione simile. Il modulo è stato chiamato dopo il nome del progetto, però, e potrebbe eseguire alcune altre funzioni: il caricamento di alcune variabili di configurazione specifici dell'ambiente (posizioni dei dati, le credenziali per i database dev / prod, per esempio), l'elaborazione di alcuni argomenti della riga di comando, e l'impostazione 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.)