instalar - ¿Cómo puedo hacer que un paquete Ruby gem copie los archivos a ubicaciones arbitrarias?
list gems installed (3)
No debería querer / necesitar hacer esto ... las gemas están diseñadas para ser usadas como bibliotecas ... no como aplicaciones en sí mismas (investigue su sistema de paquetes de aplicaciones de distros para ese tipo de cosas).
Tú lo sabes. Y yo sé que. Pero "ellos" no lo saben. Durante muchas lunas, las consultas y comentarios regulares fueron: "¿Hay alguna gema?" "¿Se puede instalar esto como una gema?" "¿Por qué no haces una gema?" "No instalé esto porque no es una joya".
Bien o no, deseable o no, Joe Rubyist espera que todo sea gemificado. Solo los alumnos de edad avanzada están familiarizados con el tipo de "ruby setup.rb" y parecen tolerarlo.
De todos modos, mi aplicación es realmente una aplicación independiente; No puedo imaginar a nadie incluyendo esto como una biblioteca. Tal vez como parte de una colección de aplicaciones, pero ... el uso como biblioteca parece bastante exagerado, pero si ese día alguna vez llegara, cruzaré ese puente cuando llegue a él (para ayudar a las personas con cualquier conflicto que inclusión podría traer).
Y no hay distinción "dev / test / stage / prod". Es una aplicación Plain Old, la ejecuta desde la línea de comandos.
De todos modos, gracias por sus comentarios, al menos mis suposiciones se afirman en que el sistema Rubygems no proporciona una manera de hacer esto.
Supongamos que tiene un paquete de software. Quieres convertirlo en una joya, porque las gemas son la forma estándar de facto de distribuir cualquier cosa en el mundo de Ruby. Las gemas son geniales, para las bibliotecas. Pero para aplicaciones reales, el sistema Rubygems parece carecer. Solo "recientemente" introdujeron una forma de marcar los ejecutables para colocarlos en alguna parte del sistema PATH ejecutable en todo el sistema. Desafortunadamente, las gemas de Ruby todavía parecen carecer de otros aspectos de los paquetes de software, es decir, poner los archivos de configuración en lugares como / etc, o la documentación en / usr / share / doc. ¿O es eso? Mi pregunta es:
¿Puedo poner instrucciones o código en gemspec para tener la configuración instalada en / etc, y la documentación en algún lugar sensible y estandarizado (como / usr / share / doc)? O tal vez, como solución, ¿se puede ejecutar un script posterior a la instalación para hacer estas cosas?
Para referencia: la especificación GemSpec .
Tenga en cuenta que rubygems.org está inactivo en el momento de escribir esto. Aquí está el caché de Google de esa página: http://74.125.95.132/search?q=cache:JwJO6slR4BwJ:www.rubygems.org/read/chapter/20+http://www.rubygems.org/read/chapter/ 20% 23página85 & hl = es & ct = clnk & cd = 1
Si examina el archivo specification.rb en el repositorio y se desplaza hacia el final (busque ": sección: atributos de gemspec obligatorios"), puede ver lo que parecen ser los atributos admitidos actualmente. No veo nada allí que se parezca a lo que quiero.
La respuesta corta: no
La respuesta larga: no debería querer / necesitar hacer esto ... las gemas están diseñadas para ser usadas como bibliotecas ... no como aplicaciones por sí mismas (investigue su sistema de paquetes de aplicaciones de distros para ese tipo de cosas). Además, no puedes asumir que tu gema solo se usará "una vez" ... en teoría, varios proyectos / aplicaciones podrían incluir tu gema, y si bien hay algunas características específicas de tu gema que la imposibilitan para algo que podría configurarse globalmente ... aún no desearía hacer eso debido a otras inquietudes de arquitectura tales como desarrollar / configurar su aplicación para trabajar en diferentes entornos de fase (desarrollo / prueba / etapa / producción). El mejor caso en el que podría terminar es simplemente observar cómo crear los archivos / etc / config en el archivo README e incluir una aplicación de utilidad para solicitar al usuario los valores.
2015-11-11 Aquí está la situación: RubyGems es compatible con los anzuelos pre y post instalación / desinstalación como extensiones del comando gem . En otras palabras, estos ganchos se aplican a todas las gemas que están instaladas y no están diseñadas para ser personalizadas en una gema específica. Se invocan en un archivo llamado operating_system.rb generalmente se encuentra en /usr/lib64/ruby/2.2.0/rubygems ; o en cualquier ubicación y versión en que Ruby esté instalado. Los ganchos se emplean así:
# /usr/lib/ruby/x.y.z./rubygems/operating_system.rb
Gem.pre_install do | installer |
# do whatever
end
Gem.pre_uninstall do | installer |
# do whatever
end
Gem.post_install do | installer |
# do whatever
end
. . .
Al profundizar en la documentación de la API, parece que para emplear actividades externas específicas de una gema, uno tiene complementos disponibles. Ver: http://guides.rubygems.org/plugins/#executablehooks y https://github.com/rvm/executable-hooks como un ejemplo. Sin embargo, todos estos parecen afectar la aplicación RubyGem en general en lugar de una gema específicamente. Y dichos complementos deben instalarse como gemas para que tengan efecto.
Me parece que los anzuelos pre y post instalación específicos de gemas son un problema de seguridad. Alguien que instale una Gema de nivel de sistema tiene por definición privilegios de root y permite que RubyGem realice acciones arbitrarias fuera de simplemente instalar una biblioteca tiene implicaciones de seguridad obvias.
Estoy comprobando con la gente de Ruby en esto (2015-11-10). Es posible que estos ganchos sean solo para personas que instalen RubyGem en diferentes plataformas.
RubyGems ahora (2015) admite los pre_install() y post_install() como métodos que toman un & bloque como sus argumentos. Es de suponer que puede hacer lo que quiera en cualquiera de estos, siempre que no devuelva false de ninguno de los dos. La devolución de nil está bien, pero un retorno false anulará la instalación de gema.