CLI to Aid Versioning di Input, Source e Output

0

Attualmente sto lavorando in un ambiente in cui ho il seguente:

  1. Input multipli (con più versioni)
  2. Codice sorgente per generare output (più versioni)
  3. 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.

link

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.

    
posta faulty_ram_sticks 23.08.2017 - 17:37
fonte

2 risposte

2

Secondo me, ecco le risposte:

  1. Quali sono altri possibili approcci qui?

    • Finché gli input e gli output sono file di testo, non ci sono difficoltà nel versionarli con il codice, quindi lo farei per rimuovere file come "input1-v1" e "input1-v2";
    • Detto questo, fornirei un makefile nella radice del progetto, che avrà tutti i comandi (l'esecuzione del tuo master script sarebbe un obiettivo in questo makefile); il target di esecuzione riceverà come parametro l'input che si sta elaborando, quindi il makefile passa semplicemente questo parametro al codice sorgente principale (compilato tramite il makefile se necessario);
    • dopo l'elaborazione di tutti gli input, la versione degli output e il commit di tutto sul server, creando un TAG per riportare tutti gli esperimenti a una versione specifica
  2. Il vincolo linguistico arbitrario sugli script impedisce una progettazione migliore?

    • Se utilizzi il makefile o un altro approccio simile, la lingua o l'SDK non dovrebbe essere un problema, anche il sistema operativo non dovrebbe essere un problema;
  3. Da un punto di vista dell'ingegneria del software, quali vincoli potrebbero / devo rilassarmi per rendere questo design migliore?

    • In primo luogo, dobbiamo comprendere le tue preoccupazioni, i tuoi bisogni e i tuoi limiti; da quello che ho ottenuto, ho suggerito i passaggi precedenti per soddisfare i requisiti di versioning; Non cambierei alcun vincolo in base a ciò che hai descritto nella tua domanda.
risposta data 23.08.2017 - 19:43
fonte
1

Codifica lo schema di denominazione dei file di input / output nel programma

Considera semplicemente la cottura dello schema di denominazione dei file di input / output nel programma. se lo fai tu, allora i tuoi argomenti specificheranno la directory di input; il percorso della directory di output verrà automaticamente derivato dalla directory di output di base e dal nome della directory di input. La directory di output di base potrebbe essere hardcoded o relativa alla directory di input o relativa all'eseguibile. È possibile consentire a un argomento di sovrascrivere la directory di output di base per il test.

Scrivi un piccolo script per ciascuna directory di input

In questo approccio, crei un piccolo script per ogni directory di input. Quello script codifica la directory di output. Questo sostituisce la logica che stai immaginando con te semplicemente creando uno script e digitando nella giusta directory. Questo trasforma i nomi delle directory di output da "completamente automatico" a "semi automatico": si configura manualmente la directory di output una sola volta, quando si crea lo script.

Usa marca

In questo approccio, si usa make per eseguire il programma (e possibilmente per costruirlo). Crea incapsula la regola per derivare la directory di output dalla directory di input. Se lo desideri, puoi configurare make per rieseguire il programma quando il programma cambia o quando i dati di input cambiano. È possibile creare una regola che esegua il programma su ogni directory di input, se lo si desidera.

Questo è il mio approccio preferito: è una sorta di design per cui è stata progettata. Anche se il suo DSL può essere un po 'criptico, funziona molto bene per cose come questa.

    
risposta data 23.08.2017 - 18:22
fonte

Leggi altre domande sui tag