Quiero crear la aplicación Ruby (no rieles). Esta es una aplicación de consola que deberá conservar algunos datos. Estoy usando pstore como la base de datos. Quiero implementar esta aplicación como una gema.Ruby Gems con datos persistentes

Mi pregunta es: ¿dónde viven mis datos?

Actualmente he creado un directorio de datos como hermano en el directorio bin en un diseño de gemas estándar. Por lo tanto, esperaría que la gema almacenara sus datos "dentro de sí misma" después de que se desplegara. Pero cuando realizo una prueba local de gema para probar, descubro que los datos se almacenan localmente en los archivos del proyecto, no en algún lugar dentro del directorio gems.

Por supuesto, podría ser que simplemente no entiendo lo que "rake install_gem" está haciendo. Además, estoy vagamente preocupado de que si necesito sudo instalar la gema, realmente será capaz de crear el archivo de datos "dentro de sí mismo" en el directorio gem.

¿Alguien puede aclarar esto un poco?

Gracias. John Schank

@makevoid - gracias por la respuesta. Aquí está la totalidad de mi guión principal. En el directorio/bin ... (he añadido a la pregunta principal, porque no estoy familiarizado con cómo formatear el contenido en un comentario - y el código pegado un aspecto horrible

#!/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

Fuente

2010-01-02 jschank

¿Puede imprimir y decirnos la ruta donde se está guardando el archivo de su PStore? ¿Eso es en tu ruta de carga de gema primaria? (* gem env * para resolverlo) – makevoid

Agregué los detalles a la publicación original, porque los comentarios no parecen tener tantas capacidades de edición – jschank

OK, así que parece que quiero usar la respuesta publicada por Johannes, y probablemente haga algo así como buscar ENV ["timesheet_home"] para que los usuarios puedan anular la ubicación, volver a ENV ["HOME"] más alguna ubicación estándar como en la respuesta de Johannes. Y falla, con una explicación, si ninguno está configurado. ¡Gracias a todos los que respondieron! – jschank

En Linux hay dos común. lugares utilizados para el almacenamiento de datos variables.

/home/user/.application

Si cada usuario tiene su propio almacenamiento de esto generalmente se hace en el directorio personal del usuario. el camino para su almacenamiento en el directorio personal del usuario debe ser

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

/var/lib/aplicación

Si todos los usuarios comparten el almacenamiento o la aplicación está destinada a ser dirigida por un solo usuario (la mayoría de los demonios),/var es el lugar adecuado para almacenar todo tipo de datos.

/var/log para los registros
/var/run para PID
/var/lock de archivos de bloqueo
/var/www para httpservers
/var/tmp para no es importante, pero los datos persistentes
/var/lib para todos los demás datos

El camino para su almacenamiento en/var debería ser

"/var/lib/" + $application_name

Asegúrese de que, los permisos de este directorio son tales, que no tiene que dejar que su aplicación se ejecute como root.

Fuente

2010-01-02 15:18:21 johannes

Había pensado hacer algo como esto, pero estaba preocupado de que no funcionara en Windows. ¿Hay un giro diferente en este tema para hacerlo en una plataforma cruzada? o esta técnica también funcionará en Windows? (¿Windows define previamente una variable de entorno "HOME"?) – jschank

Además, ¿leo eso correctamente, en que los appdata van en un directorio de archivos dot cuando están en el espacio de usuario, pero en shared van en una carpeta que no es de archivos dotfile?/var/lib? o debería ser /var/lib/.application? Gracias! John – jschank

Eso es correcto. Los archivos de puntos son archivos ocultos en Unix. Por lo tanto, el usuario normalmente no ve estos archivos de configuración en su directorio de inicio. No tiene sentido hacerlos invisibles en/var/lib. – johannes

Definitivamente no desea almacenar datos dentro del directorio gem. El comportamiento esperado es que los usuarios puedan desinstalar y reinstalar gemas sin ningún problema.Si tiene datos en el directorio instalado de su gema, la desinstalación de la gema destruirá esa información y molestará a sus usuarios.

johannes tiene las ideas correctas para usar en Linux. Para una Mac, los directorios específicos serían un poco diferentes. Lo mismo vale para Windows. Necesitará investigar cuáles son los lugares correctos para cada plataforma a la que desea apuntar y hacer que su código cambie de forma condicional las ubicaciones de almacenamiento según el tipo de host en el que se ejecute.

No olvides dejar que los usuarios anulen tus valores predeterminados. Una forma de hacerlo les hará muy felices :)

Fuente

2010-01-02 22:02:29 edebill

Hmm, sobre la desinstalación, tiene sentido. Sin embargo, no estoy seguro de cómo anular el valor predeterminado en este caso. A menos que el usuario haga algo así como establecer una variable de entorno. Porque la aplicación creará el almacén de datos en alguna ubicación, y cada comando invocado deberá volver a esa ubicación. (y no quiero tener que especificar la ubicación del almacén de datos con cada comando) ¿Alguien sabe cómo determinar la plataforma de ejecución en tiempo de ejecución, en ruby? – jschank

hay una RUBY_PLATFORM constante que debería permitirle determinar la plataforma. Las variables de entorno son una excelente manera de dejar que las personas anulen los valores predeterminados. Después de todo, si están anulando los valores predeterminados, deberían ser un usuario más sofisticado que pueda manejar algo así. – edebill

Ruby Gems con datos persistentes

Respuesta

/home/user/.application

/var/lib/aplicación

Cuestiones relacionadas