Attualmente sto lavorando in un ambiente in cui ho il seguente:
- Input multipli (con più versioni)
- Codice sorgente per generare output (più versioni)
- Output generato da una combinazione di input e codice sorgente
La directory di primo livello assomiglia a questa:
inputs/
outputs/
src/
Mi piacerebbe un po 'generalizzare questo concetto e creare uno script che mi aiuti a tenere traccia automaticamente delle informazioni necessarie per generare un determinato output.
Finora, mi sono accordato sulla seguente struttura gerarchica per aiutarmi a farlo:
input /
Terrò traccia di ogni insieme discreto di input in una cartella. Sebbene l'utilizzo di Git sia potenzialmente possibile, tracciare file di grandi dimensioni, possibilmente binari, non sembra ancora fattibile in Git. Quindi, ad esempio, imposterò questa struttura di directory come tale:
inputs/inputs-1-v1
inputs/inputs-1-v2
inputs/inputs-1-v3
inputs/inputs-2-v1
src /
Codice sorgente, controllato dalla versione di Git. Questi sono pensati per rappresentare esperimenti o analisi distinti e possono essere in qualsiasi linguaggio arbitrario. Esempio:
script-1
script-2
uscite /
Supponiamo che input / input-1-v1 sia dato come input per lo script-2. Quindi, verrà generata la cartella di output risultante:
outputs/script-2/git-hash/inputs-1-v1
Questa struttura è flessibile e ci sto semplicemente pensando, ma non proprio perché sto facendo la mia domanda. Ho pensato che fosse necessario dare qualche background.
Question (s)
Attualmente sto pianificando di scrivere uno script "master" che posso utilizzare per questa architettura di progetto generica, che posso eseguire dalla directory di livello superiore:
run -c "script parameter 1 parameter2" -i <inputs folder>
Ciò comporterebbe una semplice espansione di comando a quanto segue:
src/script parameter1 parameter2 -i ../inputs/input-folder -o ../outputs/script/git-hash/input-folder > ../outputs/script/git-hash/input-folder/stdout.txt 2> ../outputs/script/git-hash/input-folder/stderr.txt
Tuttavia, questo mi sembra molto schifoso. Forza i miei script ad esporre una CLI che accetta gli argomenti -i e -o. Evoca la domanda sul perché scrivere un master script di questo tipo, ma ritengo che astrarre l'idea di creare queste cartelle di output sia un buon piano, piuttosto che ripetere quella logica in un certo numero di script separati.
Penso che quello che mi infastidisce di più è la mancanza di qualsiasi dichiarazione di un'interfaccia formale. Sto richiedendo all'implementatore di aggiungere queste opzioni -i e -o ai propri script. Ad esempio, se si trattava di una classe Java, potrei creare un'interfaccia Experiment e farla implementare da script1.
Quello che intuisco dovrebbe accadere è qualcosa di più di Unixia, in cui potrei collegare l'input dalla cartella di input e semplicemente reindirizzare l'output dello script senza dover avere esplicitamente i file di scrittura dello script. Tuttavia, questo è complicato dal fatto che lo script potrebbe scrivere diversi file (file immagine, file di testo, ecc.) E leggere diversi file per un dato input.
Quindi, in sintesi, ti sto chiedendo:
- Quali sono altri possibili approcci qui?
- Il vincolo linguistico arbitrario sugli script impedisce una progettazione migliore?
- Da un punto di vista dell'ingegneria del software, quali vincoli potrebbero / devo rilassarmi per rendere questo design migliore?
Ho trovato la seguente domanda correlata, ma è più una domanda sulla struttura.
Modifica: Forse la seguente domanda è più chiara: qual è il modo migliore per me di comunicare il fatto che lo script subordinato dovrebbe scrivere il suo output in una determinata directory? Lo script dovrebbe sapere anche dove dovrebbe scrivere il suo output, o sarebbe meglio provare a scrivere qualcosa come stdout? L'approccio che ho descritto sopra richiede all'utente di sapere che il loro script ha bisogno dell'interfaccia esplicita definita sopra, e non so se questo è un buon progetto.