bundle-exec - Ejecutar un comando en el contexto del paquete
bundle exec [--keep-file-descriptors] command
Este comando ejecuta el comando, haciendo que todas las gemas especificadas en el [Gemfile(5)][Gemfile(5)] estén disponibles para requerir en los programas de Ruby.
Esencialmente, si hubiera ejecutado normalmente algo como rspec spec/my_spec.rb, y desea usar las gemas especificadas en el [Gemfile(5)][Gemfile( 5)] e instalado a través de bundle install(1) bundle-install.1.html, debe ejecutar bundle exec rspec spec/my_spec.rb.
Tenga en cuenta que bundle exec no requiere que haya un ejecutable disponible en la ` PATH de su shell.
Exec en Ruby 2.0 comenzó a descartar descriptores de archivos no estándar. Cuando se pasa este indicador, exec volverá al comportamiento 1.9 de pasar todos los descriptores de archivo al nuevo proceso.
Si usa el indicador --binstubs en bundle install(1) bundle-install.1.html, Bundler creará automáticamente un directorio (que por defecto es app_root /bin) que contiene todos los ejecutables disponibles de gemas en el paquete.
Después de usar --binstubs, bin/rspec spec/my_spec.rb es idéntico a bundle exec rspec spec/my_spec.rb.
bundle exec realiza una serie de cambios en el entorno de shell y luego ejecuta el comando que especifique en su totalidad.
asegúrese de que todavía es posible pagar a paquete desde dentro de un comando invocado por bundle exec (usando $BUNDLE_BIN_PATH)
coloque el directorio que contiene los ejecutables (como rails, rspec, rackup) para su paquete en ` PATH
asegúrese de que si se invoca el paquete en la subcapa, use el mismo Gemfile (configurando BUNDLE_GEMFILE)
agregue -rbundler/setup a $RUBYOPT, lo que garantiza que los programas de Ruby invocados en el subshell puedan ver las gemas en el paquete
También modifica Rubygems:
no permitir la carga de gemas adicionales que no estén en el paquete
modifique el método gem para que no sea operativo si hay una gema que cumple con los requisitos en el paquete, y para generar un Gem::LoadError si no lo está
Defina Gem.refresh para que no funcione, ya que el índice de origen siempre se congela cuando se usa el paquete y para evitar que las gemas del sistema se filtren en el entorno.
Anule Gem.bin_path para usar las gemas en el paquete, haciendo que los ejecutables del sistema funcionen
Agregue todas las gemas del paquete en Gem.loaded_specs
Finalmente, bundle exec también modifica implícitamente Gemfile.lock si el archivo de bloqueo y el Gemfile no coinciden. Bundler necesita el Gemfile para determinar cosas como los grupos de gemas, requisitos automáticos y plataformas, etc., y esa información no se almacena en el archivo de bloqueo. El Gemfile y el archivo de bloqueo deben estar sincronizados para empaquetar exec con éxito, por lo que empaquetar exec actualiza el archivo de bloqueo de antemano.
De forma predeterminada, al intentar empaquetar exec a un archivo con un ruby shebang, Bundler Kernel.load ese archivo en lugar de usar Kernel.exec . En la gran mayoría de los casos, se trata de una mejora del rendimiento. En algunos casos excepcionales, esto podría causar algunos efectos secundarios sutiles (como la dependencia del contenido exacto de $0 o __FILE__) y la optimización se puede desactivar habilitando el configuración disable_exec_load.
Cualquier código de Ruby que abra una subcapa (como sistema, acentos graves o %x{}) usará automáticamente el entorno de Bundler actual. Si necesita pagar un comando de Ruby que no forma parte de su paquete actual, use el método with_unbundled_env con un bloque. Cualquier subcapa creada dentro del bloque recibirá el entorno presente antes de que se activara Bundler. Por ejemplo, los comandos de Homebrew ejecutan Ruby, pero no funcionan dentro de un paquete:
Bundler.with_unbundled_env do
`brew install wget`
endTambién es necesario usar with_unbundled_env si está pagando por un paquete diferente. Cualquier comando de Bundler que se ejecute en una subcapa heredará el Gemfile actual, por lo que los comandos que deben ejecutarse en el contexto de un paquete diferente también deben usar with_unbundled_env.
Bundler.with_unbundled_env do
Dir.chdir "/other/bundler/project" do
`bundle exec ./script`
end
endBundler proporciona asistentes convenientes que envuelven system y exec, y se pueden usar de esta manera:
Bundler.clean_system('brew install wget')
Bundler.clean_exec('brew install wget')Actualmente, el sistema de complementos de Rubygems requiere todos los archivos denominados rubygems_plugin.rb en la ruta de carga de cualquier gema instalada cuando cualquier código de Ruby requiere rubygems.rb. >. Esto incluye ejecutables instalados en el sistema, como rails, rackup y rspec.
Dado que los complementos de Rubygems pueden contener código Ruby arbitrario, por lo general terminan activándose ellos mismos o sus dependencias.
Por ejemplo, la gema gemcutter 0.5 dependía de json_pure. Si tuviera esa versión de gemcutter instalada (incluso si también tuviera una versión más nueva sin este problema), Rubygems activaría gemcutter 0.5 y json_pure
Si su Gemfile(5) también contenía json_pure (o una gema que dependía de json_pure), la última versión de su sistema podría entrar en conflicto con la versión de su Gemfile(5 ), o la versión instantánea en su Gemfile.lock.
Si esto sucede, el paquete dirá:
You have already activated json_pure 1.4.6 but your Gemfile
requires json_pure 1.4.3. Consider using bundle exec.En esta situación, es casi seguro que desee eliminar la gema subyacente con el complemento de gema problemático. En general, los autores de estos complementos (en este caso, la gema gemcutter) han lanzado nuevas versiones que son más cuidadosas en sus complementos.
Puede encontrar una lista de todas las gemas que contienen complementos de gemas ejecutando
ruby -e "puts Gem.find_files('rubygems_plugin.rb')"Como mínimo, debe eliminar todos los complementos de gemas, excepto la versión más reciente, y también eliminar todos los complementos de gemas que no esté utilizando (gem uninstall gem_name).