Desidero creare l'applicazione di rubino (non i binari). Questa è un'app per console che dovrà conservare alcuni dati. Sto usando pstore come database. Voglio distribuire questa applicazione come una gemma.Ruby Gems con dati persistenti

La mia domanda è: dove vivono i miei dati?

Attualmente ho creato una directory di dati come un fratello della directory bin in un layout gem standard. Pertanto, mi aspetto che la gemma memorizzi i suoi dati "dentro se stessa" dopo che è stata distribuita. Ma quando eseguo un'installazione gem locale da testare, trovo che i dati vengano archiviati localmente nei file di progetto, non da qualche parte all'interno della directory gems.

Ovviamente potrebbe essere che ho capito male cosa sta facendo "rake install_gem". Inoltre, sono vagamente preoccupato che se ho bisogno di sudo per installare la gemma, sarà effettivamente in grado di creare il file di dati "dentro se stesso" nella directory gem.

Qualcuno può chiarirlo un po '?

Grazie. John Schank

@makevoid - grazie per la risposta. Ecco la totalità del mio copione principale. Nella directory/bin ... (ho aggiunto alla domanda principale perché io non sono a conoscenza di come formattare il contenuto in un commento - e il codice incollato sembrava orribile

#!/usr/bin/env ruby 

$LOAD_PATH.unshift File.dirname(__FILE__) + '/../lib' 

require 'timesheet' 

begin 
    command_hash = TimesheetParser.parse 
    store = YAML::Store.new("data/time_entries.yaml") 
    tl = TimeLog.new(store) 
    ts = Timesheet.new(tl) 
    ts.process(command_hash) 
rescue Exception => e 
    raise if command_hash[:debug] 
    puts e.message

fonte

2010-01-02 jschank

puoi stampare e dirci il percorso in cui viene salvato il tuo file PStore? È nel tuo percorso di caricamento della gemma primaria? (* gem env * per capirlo) – makevoid

Ho aggiunto i dettagli al post originale, perché i commenti non sembrano avere capacità di modifica avanzate – jschank

OK, quindi sembra che voglio usare la risposta inviata da Johannes, e probabilmente fare qualcosa come cercare ENV ["timesheet_home"] in modo che gli utenti possano ignorare la posizione, tornare a ENV ["HOME"] più una posizione standard come nella risposta di Johannes. E fallire, con una spiegazione, se nessuno dei due è impostato. Grazie, tutti quelli che hanno risposto! – jschank

Su Linux ci sono due comuni. luoghi utilizzati per la memorizzazione di dati variabili.

/home/user/.application

Se ogni utente ha bisogno è proprio la conservazione questo di solito è fatto nella home directory degli utenti. il percorso per la memorizzazione nella home directory degli utenti dovrebbe be

ENV["HOME"] + "/." + $application_name

/var/lib/dell'applicazione

Se tutti gli utenti condividono lo stoccaggio o l'applicazione è destinato a essere gestito da un solo utente (la maggior parte dei demoni),/var è il posto giusto per memorizzare tutti i tipi di dati.

/var/log per i registri
/var/run per PID
/var/lock per bloccare i file
/var/www per httpservers
/var/tmp per non importante, ma i dati persistenti
/var/lib per tutti gli altri dati

Il percorso per l'archiviazione in/var dovrebbe essere

"/var/lib/" + $application_name

Assicurarsi, le autorizzazioni per questa directory sono tali, che non si deve lasciare che la corsa di applicazione come root.

fonte

2010-01-02 15:18:21 johannes

Avevo pensato di fare qualcosa del genere, ma ero preoccupato che non funzionasse su Windows. C'è una svolta diversa su questo tema per renderlo multipiattaforma? o questa tecnica funzionerà anche su Windows? (Windows pre-definisce una variabile di ambiente "HOME"?) – jschank

Inoltre, ho letto bene, in quanto l'app va in una directory dotfile quando è nello spazio utente, ma in condivisa va in una cartella non-dotfile per/var/lib? o dovrebbe essere /var/lib/.application? Grazie! John – jschank

Proprio così. I dotfile sono file nascosti in unix. Quindi l'utente non vede normalmente questi file di configurazione nella sua home directory. Non ha senso renderli invisibili in/var/lib. – johannes

Sicuramente non si desidera memorizzare i dati all'interno della directory gem. Il comportamento previsto è che gli utenti possono disinstallare e reinstallare gems senza problemi.Se hai dei dati nella directory installata della tua gemma, disinstallare la gemma distruggerà quei dati e farà incazzare i tuoi utenti.

johannes ha le idee giuste per l'uso su Linux. Per un Mac le directory specifiche sarebbero un po 'diverse. Lo stesso vale per Windows. Avrai bisogno di cercare quali sono i posti giusti per ogni piattaforma che vuoi targetizzare e il tuo codice cambierà condizionalmente le posizioni di archiviazione a seconda del tipo di host su cui viene eseguito.

Non dimenticare di consentire agli utenti di ignorare le impostazioni predefinite. Un modo per farlo li renderà molto felici :)

fonte

2010-01-02 22:02:29 edebill

Hmm, sulla disinstallazione, ha senso. Tuttavia, non sono sicuro di come sovrascrivere il valore predefinito in questo caso. A meno che l'utente non faccia qualcosa come impostare una variabile d'ambiente. Poiché l'app creerà l'archivio dati in qualche posizione e ogni comando richiamato dovrà tornare a quella posizione. (e non voglio dover specificare la posizione dell'archivio dati con ciascun comando) Qualcuno sa come determinare la piattaforma di esecuzione in fase di esecuzione, in ruby? – jschank

c'è un RUBY_PLATFORM costante che dovrebbe consentire di determinare la piattaforma. Le variabili di ambiente sono un modo eccellente per consentire alle persone di ignorare le impostazioni predefinite. Dopotutto, se stanno ignorando i valori predefiniti dovrebbero essere utenti più sofisticati in grado di gestire qualcosa di simile. – edebill

Ruby Gems con dati persistenti

risposta

/home/user/.application

/var/lib/dell'applicazione

Problemi correlati