2010-08-05 9 views

Respuesta

8

No he tenido que hacer esto todavía, pero creo que todo se maneja por bundler.

Cuando crea una nueva aplicación rails3, las dependencias de los raíles se ponen en su Gemfile. Puede ejecutar bundle install para instalarlos. Por defecto, están instalados en su BUNDLE_PATH.

Si desea instalarlos en su aplicación, puede especificar dónde: bundle install vendor/gems.

+2

También puede ejecutar "paquete pacK" y terminarán en el directorio "proveedor/caché /". –

+1

Para aclarar (como comentario a esta respuesta, basado en otras respuestas [y comentarios a esas respuestas]), gemas congeladas no es tan útil como lo era una vez que está usando Bundler para administrar sus dependencias de gemas porque Bundler proporciona la mayor parte de la funcionalidad previamente otorgada por las gemas de congelación. –

+0

Como han dicho otras respuestas y comentarios, este es el enfoque correcto si ** necesitas ** para congelar tus gemas en tu aplicación, generalmente porque las has modificado. – nfm

1

Asumiendo que ya tienen instalados bundlergem:

  • $ bundle lock
  • $ git add Gemfile.lock
+0

El paquete más nuevo ahora se bloquea de manera predeterminada en la instalación del paquete. –

+0

El comando está en desuso para el último Bundler. – Autodidact

21

Por lo tanto, la respuesta corta es, no lo hace.

Al modificar su Gemfile, y luego ejecutar bundle install o bundle update, bundler maneja la resolución de dependencias para usted y determina la mejor (la más reciente) versiones de cada gema que ha exigido que satisface toda la cadena de dependencia (que no lo hará obtener una nueva versión que rompa otra gema en la lista de dependencias, etc.). También puede, por supuesto, colocar una versión específica, o una especificación '> = 1.2.3' o lo que quiera en el Gemfile usando la sintaxis familiar de los config.gem días, y el paquete se asegurará de satisfacer eso también (o no lo producirá) un Gemfile.lock si no hay una resolución válida).

Cuando Bundler hace su negocio, crea el archivo Gemfile.lock, que (y esto se proporciona si usa bundler solo para administrar su gema en todas las estaciones de trabajo/entornos/implementaciones) realiza la misma función que congelar todas las gemas lo has requerido ¡Gratis! (¡Compruebe este archivo en el control de la versión!) Si su nuevo interno de desarrollo extrae su fuente en una máquina nueva, se necesita una bundle install y las mismas versiones exactas de las gemas que ha instalado están en su máquina. Empuje hacia la implementación y haga allí un bundle install --deployment (o más probablemente, colóquelo en su Capfile), y las mismas gemas están instaladas (esta vez en proveedor/paquete, configurable). Bundler se usa en Rails 3 para gestionar la carga de todas las gemas, por lo que siempre le pediste a bundler que las instale (cualquiera que sea tu ubicación normal gem install es la predeterminada BUNDLE_PATH (que está registrada en .bundle/config si la instalas con bundle install --path=foo de lo contrario), el paquete cargará los correctos, incluso cuando difieran de las gemas del sistema.

No necesita descomprimir las gemas y registrarlas en su aplicación, porque no importa: usted está garantizando se están llamando a las mismas versiones independientemente de dónde estén instaladas, lo que probablemente variará de una máquina a otra de todos modos (.undund/no debe registrarse en el repositorio), así que ¿por qué meter otros 60-80 MB de archivos en su repositorio? usted nunca va a cambiar o usar? (por cierto, esta es la razón por la que no recomendaría un bundle install --path=vendor/gemslike nfm suggested - no es necesariamente incorrecto, simplemente no hay beneficio en el flujo de trabajo normal del bundler, y ahora su tamaño de repo se ha disparado).

+0

¿Por qué este punto no se hace con mayor claridad? Heredé una aplicación existente de Rails 2.x que se ejecuta en Heroku y me ha costado entender por qué querríamos gemas instaladas bajo '. \ Vendor \ plugins' en lugar de simplemente agregarlas al bundter Gemfile. –

+1

Mi mejor opción es que, antes de Bundler, la mejor práctica era "vender todo" para que tuvieras un conjunto de instalación consistente en todos tus espacios de trabajo/objetivos de despliegue (que se remonta a [esta publicación del blog] (http: //errtheblog.com/posts/50-vendor-everything), lo mejor que puedo decir, y que cuando ves las gemas agrupadas pegadas en el proveedor, solo está utilizando el patrón anterior y no aprovecha al máximo Bundler. –

+1

- casi seguro que eres correcto.Lo que ayudó a entender las diferentes opciones disponibles es que, aunque un complemento (Rails) se puede empaquetar como una gema (Ruby), las gemas no siempre son complementos. Pero finalmente me di cuenta de que la razón por la que había 'gems' instaladas en '. \ Vendor \ plugins' es simplemente que (a) ellos * son * complementos, y (b) el desarrollador anterior eligió adoptar la convención (razonable) de vendorizing (plugin) gems en esa carpeta (en lugar de decir '. \ vendor \ gems'). –

18

¡NO USE LA RESPUESTA "RECOMENDADA" DE NFM!

lugar, revise el sitio Bündler, en particular la página en los despliegues: http://gembundler.com/deploying.html

El breve resumen es el uso de versiones específicas en su Gemfile y ejecutar bundle install --deployment en cada sistema de destino donde necesitará las versiones exactas de la gema.

Al usar la opción --path se instalarán las gemas, pero en realidad no es lo que quieres hacer. Como dijo Matt Enright, simplemente abotas a tu SCM con cosas que el bundler puede manejar inteligentemente en cada entorno objetivo.

+1

Una razón por la que solía utilizar los rieles: congelar era para poder piratear el código de los rieles, a menudo para ayudarme a depurarlo. paquete paquete simplemente me da archivos .gem. – mcr

+0

¿Qué sucede si no tiene la raíz en el sistema de destino y no puede instalar las gemas? Por ejemplo, si tiene el servidor de producción en una empresa de hosting? –

-1

Bueno, tengo que modificar ligeramente una de las gemas que necesito. Entonces necesito mantenerlo dentro de mi Repo. Entonces, lo que NFM mencionó es lo que probablemente necesito.

0

Pod - Si es necesario modificar la gema, la mejor práctica para hacer esto sería bifurcan el proyecto, realizar el cambio, a continuación, utilizando la bandera 'git' en bundler:

git 'some_gem', :git => 'git://github.com/me/my_forked_some_gem.git'

Este forma en que se le notificará cuando se actualice la gema.

0

El comando que desea es bundle package que acaba de desempaquetar las gemas y dependencias en la carpeta vendor/cache.

Pero solo un aviso, el tipo de gemas :git => .... no será empaquetado. Tienes que hackear una salida para :git => ... gemas relacionadas para empacar.

7

Tuve que hacer esto para el despliegue de gemas de typus en Heroku ya que no se puede ejecutar un heroku rails generate typus en Heroku dado que es un sistema de archivos de solo lectura. No quería poner TODAS las gemas en mi aplicación, solo la que me causaba dolor. Estos son los pasos que conducen al éxito:

  1. crear el directorio en nombre_apl/vendedor/joyas/gem_name (opcional) ... en mi caso/nombre_apl/vendedor/joyas/typus

  2. añadir el siguiendo a gemfile (esto le dice a bundle dónde encontrar y poner la fuente de la gema):

    gem 'typus',: git => 'https://github.com/fesplugas/typus.git',: path => "proveedor/gems/typus"

  3. luego desde su directorio de aplicaciones (esto instala la gema en su aplicación):

    'joya de desempaquetado typus --target vendedor/joyas/typus'

  4. continuación bundle install

  5. entonces .. en mi caso ... cometer y empujar al repositorio y luego desplegar hasta heroku ...puede que tenga que ejecutar un heroku rake db:migrate

+0

'gem unpack' no usa bundler, por lo que no tiene idea sobre el git repo especificado en el Gemfile. En cambio, irá a rubygems e intentará buscar la última versión desde allí. –

-1

Una gran cantidad de comentarios son un poco diciendo que es no es útil usar el paquete install --path vendor/gems, pero las personas que usan Dreamhost deben tener en cuenta que no se puede usar la instalación del paquete en Dreamhost.

La solución es colocar todas las gemas en la carpeta del proveedor y cargar todo en el directorio de Dreamhost.

Existen otras soluciones para revertir esto, pero es mucho más complicado de hacer.

+0

'bundle install' funciona en Dreamhost – k107

1

Puede agrupar la instalación en Dreamhost sin ningún problema. Si está compartido, el entorno ya está configurado para almacenarlos localmente en su directorio de inicio. Si usted está en un VPS o dedicados Puede ejecutar bundle instalar como root o simplemente agregar esto a su .bash_profile

export GEM_HOME=$HOME/.gems 
export GEM_PATH=$GEM_HOME:/usr/lib/ruby/gems/1.8 
1

Respondo la respuesta de tsega (actualizado por coreyward). "paquete paquete" es la respuesta genérica.

El cartel no preguntó SI DEBERÍA congelar sus gemas. Él quería saber CÓMO. Las respuestas como "Simplemente no lo hagas" no son útiles en absoluto. Sí, resultó que su problema específico era un poco diferente a eso, pero mientras que el "paquete paquete" podría haber sido excesivo, todavía resuelve el problema.

He trabajado en muchos sistemas y en algunos simplemente no tiene acceso completo. Instalar gemas en algunos sistemas simplemente no es una opción. Entonces a menos que los empaque, en general está jodido. Existen diferentes soluciones para diferentes hosts y sistemas, pero ninguna para algunos.

Cuestiones relacionadas