bundle-install - Instale as dependências especificadas em seu Gemfile
bundle install [--binstubs[=DIRECTORY]] [--clean] [--deployment] [--frozen] [--full-index] [--gemfile=GEMFILE] [--jobs=NUMBER] [--local] [--no-cache] [--no-prune] [--path PATH] [--quiet] [--redownload] [--retry=NUMBER] [--shebang] [--standalone[=GROUP[ GROUP...]]] [--system] [--trust-policy=POLICY] [--with=GROUP[ GROUP...]] [--without=GROUP[ GROUP...]]
Instale as gems especificadas em seu Gemfile(5). Se esta for a primeira vez que você executa a instalação do pacote (e um Gemfile.lock não existe), o Bundler buscará todas as fontes remotas, resolverá as dependências e instalará todas as gems necessárias.
Se um Gemfile.lock existir e você não tiver atualizado seu Gemfile(5), o Bundler buscará todas as fontes remotas, mas usará as dependências especificadas no Gemfile.lock em vez de resolver dependências.
Se um Gemfile.lock existir e você tiver atualizado seu Gemfile(5), o Bundler usará as dependências no Gemfile.lock para todas as gems que você não atualizou , mas irá resolver novamente as dependências das gems que você atualizou. Você pode encontrar mais informações sobre este processo de atualização abaixo em ATUALIZAÇÃO CONSERVATIVA.
--clean, --deployment, --frozen, --no-prune, --path, --shebang, --system, --without e --with estão obsoletas porque só fazem sentido se forem aplicadas a cada instalação de pacote subsequente executada automaticamente e isso requer que o bundler as lembre silenciosamente. Uma vez que o bundler não lembrará mais os sinalizadores CLI em versões futuras, a configuração do pacote (consulte bundle-config(1)) deve ser usada para aplicá-los permanentemente.
Binstubs são scripts que envolvem executáveis. O Bundler cria um pequeno arquivo Ruby (um binstub) que carrega o Bundler, executa o comando e o coloca em bin/. Isso permite vincular o binstub dentro de um aplicativo à versão gem exata de que o aplicativo precisa.
Cria um diretório (o padrão é ~/bin) e coloca lá qualquer executável da gem. Esses executáveis são executados no contexto do Bundler. Se usado, você pode adicionar este diretório à variável PATH do seu ambiente. Por exemplo, se a gem rails vier com um executável rails, este sinalizador criará um executável bin/rails que garante que todas as dependências referidas serão ser resolvido usando as gemas empacotadas.
Ao terminar a instalação, o Bundler removerá quaisquer gems não presentes no Gemfile(5) atual. Não se preocupe, as joias atualmente em uso não serão removidas.
Esta opção está obsoleta em favor da configuração limpa.
No modo de implantação, o Bundler "distribuirá" o pacote para produção ou uso de CI. Por favor, verifique cuidadosamente se você deseja ter esta opção habilitada em seu ambiente de desenvolvimento.
Esta opção está obsoleta em favor da configuração de implantação.
Force o download de cada gem, mesmo que as versões necessárias já estejam disponíveis localmente.
Não permita que o Gemfile.lock seja atualizado após esta instalação. Sai diferente de zero se houver alterações no Gemfile.lock.
Esta opção está obsoleta em favor da configuração congelada.
O Bundler não chamará o endpoint da API do Rubygems (padrão), mas baixará e armazenará em cache um arquivo de índice (atualmente grande) de todas as gems. O desempenho pode ser melhorado para pacotes grandes que raramente mudam ao habilitar esta opção.
A localização do Gemfile(5) que o Bundler deve usar. O padrão é um Gemfile(5) no diretório de trabalho atual. Em geral, o Bundler assumirá que o local do Gemfile(5) também é a raiz do projeto e tentará encontrar Gemfile.lock e vendor/cache relativo a este local .
O número máximo de trabalhos paralelos de download e instalação. O padrão é o número de processadores disponíveis.
Não tente se conectar a rubygems.org. Em vez disso, o Bundler usará as gems já presentes no cache do Rubygems ou em vendor/cache. Observe que, se existir uma gem específica de plataforma apropriada em rubygems.org, ela não será encontrada.
Forçar o uso de gems instaladas localmente, ou gems já presentes no cache do Rubygems ou em vendor/cache, ao resolver, mesmo se versões mais recentes estiverem disponíveis remotamente. Apenas tente se conectar a rubygems.org para gems que não estão presentes localmente.
Não atualize o cache em vendor/cache com as gems recém-empacotadas. Isso não remove nenhuma gema do cache, mas impede que as gemas recém-empacotadas sejam armazenadas em cache durante a instalação.
Não remova gems obsoletas do cache quando a instalação terminar.
Esta opção está obsoleta em favor da configuração no_prune.
O local para instalar as gems especificadas. O padrão é a configuração do Rubygems. O Bundler compartilha esta localização com Rubygems, gem install ... terá o gem instalado lá também. Portanto, as gems instaladas sem uma configuração --path ... aparecerão chamando lista de gems. Da mesma forma, as gems instaladas em outros locais não serão listadas.
Esta opção está obsoleta em favor da configuração path.
Não imprima informações de progresso na saída padrão. Em vez disso, o Bundler sairá usando um código de status ($?).
Repita as solicitações de rede ou git com falha number vezes.
Usa o executável ruby especificado (geralmente ruby) para executar os scripts criados com --binstubs. Além disso, se você usar --binstubs junto com --shebang jruby, esses executáveis serão alterados para executar jruby.
Esta opção está obsoleta em favor da configuração shebang.
Faz um pacote que pode funcionar sem depender de Rubygems ou Bundler em tempo de execução. Uma lista separada por espaços de grupos a serem instalados deve ser especificada. O Bundler cria um diretório chamado bundle e instala o pacote lá. Ele também gera um arquivo bundle/bundler/setup.rb para substituir a própria configuração do Bundler da maneira necessária. O uso desta opção define caminho implicitamente, que é uma [opção lembrada][OPÇÕES REMEMBERADAS].
Instala as gems especificadas no bundle no local Rubygems do sistema. Isso substitui qualquer configuração anterior de --path.
Esta opção está obsoleta em favor da configuração sistema.
Aplique a política de segurança Rubygems policy, onde a política é HighSecurity, MediumSecurity, LowSecurity, AlmostNoSecurity ou NoSecurity. Para mais detalhes, consulte a documentação de assinatura do Rubygems no link abaixo em VEJA TAMBÉM.
Uma lista separada por espaço de grupos referenciando gems para instalar. Se um grupo opcional for fornecido, ele será instalado. Se for fornecido um grupo que esteja na lista lembrada de grupos atribuídos a --sem, ele será removido dessa lista.
Esta opção está obsoleta em favor da configuração com.
Uma lista separada por espaços de grupos que fazem referência a gems para pular durante a instalação. Se for fornecido um grupo que esteja na lista lembrada de grupos atribuídos a --with, ele será removido dessa lista.
Esta opção está obsoleta em favor da configuração sem.
Os padrões do Bundler são otimizados para desenvolvimento. Para alternar para padrões otimizados para implantação e CI, use o sinalizador --deployment. Não ative o modo de implantação em máquinas de desenvolvimento, pois isso causará um erro quando o Gemfile(5) for modificado.
Um Gemfile.lock é necessário. Para garantir que as mesmas versões das gems com as quais você desenvolveu e testou também sejam usadas em implantações, um Gemfile.lock é necessário. Isso é principalmente para garantir que você lembre-se de verificar seu Gemfile.lock no controle de versão.
O Gemfile.lock deve estar atualizado No desenvolvimento, você pode modificar seu Gemfile(5) e executar novamente a instalação do pacote para atualizar conservadoramente seu instantâneo Gemfile.lock. Na implantação, seu Gemfile.lock deve estar atualizado com as alterações feitas em seu Gemfile(5).
As gems são instaladas no fornecedor/pacote e não no local padrão do sistema No desenvolvimento, é conveniente compartilhar as gems utilizadas em sua aplicação com outras aplicações e outros scripts que rodam no sistema. Na implantação, o isolamento é um padrão mais importante. Além disso, o usuário que implanta o aplicativo pode não ter permissão para instalar gems no sistema ou o servidor da Web pode não ter permissão para lê-los. Como resultado, bundle install --deployment instala gems no diretório vendor/bundle no aplicativo. Isso pode ser substituído usando a opção --path.
Por padrão, a instalação do pacote instalará todas as gems em todos os grupos em seu Gemfile(5), exceto aquelas declaradas para uma plataforma diferente.
No entanto, você pode dizer explicitamente ao Bundler para ignorar a instalação de determinados grupos com a opção --without. Essa opção usa uma lista de grupos separados por espaço.
Embora a opção --without pule a instalação das gems nos grupos especificados, ela ainda baixará essas gems e as usará para resolver as dependências de cada gem em seu Gemfile(5).
Isso é feito para que a instalação de um conjunto diferente de grupos em outra máquina (como um servidor de produção) não altere as gems e versões que você já desenvolveu e testou.
O Bundler oferece uma garantia sólida de que o código de terceiros que você está executando no desenvolvimento e teste também é o código de terceiros que você está executando na produção. Você pode optar por excluir parte desse código em diferentes ambientes, mas nunca será pego de surpresa por diferentes versões de código de terceiros sendo usadas em diferentes ambientes.
Para uma ilustração simples, considere o seguinte Gemfile(5):
source 'https://rubygems.org'
gem 'sinatra'
group :production do
gem 'rack-perftools-profiler'
endNeste caso, sinatra depende de qualquer versão do Rack (>= 1.0), enquanto rack-perftools-profiler depende de 1.x ( ~> 1.0).
Quando você executa instalação de pacote --sem produção no desenvolvimento, também examinamos as dependências de rack-perftools-profiler. Dessa forma, você não gasta todo o seu tempo desenvolvendo no Rack 2.0, usando novas APIs indisponíveis no Rack 1.x, apenas para que o Bundler mude para o Rack 1.2 quando o grupo de produção está usado.
Isso não deve causar nenhum problema na prática, porque não tentamos instalar as gems nos grupos excluídos, e apenas avaliamos como parte do processo de resolução de dependências.
Isso também significa que você não pode incluir versões diferentes da mesma gem em grupos diferentes, pois isso resultaria em diferentes conjuntos de dependências usadas no desenvolvimento e na produção. Por causa dos caprichos do processo de resolução de dependências, isso geralmente afeta mais do que as gems que você lista em seu Gemfile(5), e pode (surpreendentemente) mudar radicalmente as gems que você está usando.
Ao executar a instalação do pacote, o Bundler manterá os nomes completos e as versões de todas as gems que você usou (incluindo as dependências das gems especificadas no Gemfile(5)) em um arquivo chamado Gemfile. bloqueio.
O Bundler usa esse arquivo em todas as chamadas subseqüentes para instalação do pacote, o que garante que você sempre use o mesmo código exato, mesmo que seu aplicativo se mova entre as máquinas.
Devido ao modo como a resolução de dependência funciona, mesmo uma mudança aparentemente pequena (por exemplo, uma atualização para um lançamento pontual de uma dependência de uma gem em seu Gemfile(5)) pode resultar na necessidade de gems radicalmente diferentes para satisfazer todas as dependências.
Como resultado, você DEVE verificar seu Gemfile.lock no controle de versão, tanto em aplicativos quanto em gems. Caso contrário, todas as máquinas que verificarem seu repositório (incluindo seu servidor de produção) resolverão todas as dependências novamente, o que resultará em diferentes versões de código de terceiros sendo usadas se qualquer uma das gems em o Gemfile(5) ou qualquer uma de suas dependências foram atualizados.
Quando o Bundler foi enviado pela primeira vez, o Gemfile.lock foi incluído no arquivo .gitignore incluído com as gems geradas. Com o tempo, no entanto, ficou claro que essa prática força a dor das dependências quebradas em novos contribuidores, deixando os contribuidores existentes potencialmente inconscientes do problema. Como a instalação do pacote geralmente é o primeiro passo para uma contribuição, a dor de dependências quebradas desencorajaria novos contribuidores de contribuir. Como resultado, revisamos nossa orientação para os autores de gemas para agora recomendar a verificação de gemas no bloqueio.
Quando você faz uma alteração no Gemfile(5) e executa a instalação do pacote, o Bundler atualizará apenas as gems que você modificou.
Em outras palavras, se uma gem que você não modificou funcionou antes de você chamar instalação do pacote, ela continuará a usar exatamente as mesmas versões de todas as dependências que usava antes do atualizar.
Vamos dar uma olhada em um exemplo. Aqui está o seu Gemfile original (5):
source 'https://rubygems.org'
gem 'actionpack', '2.3.8'
gem 'activemerchant'Nesse caso, actionpack e activemerchant dependem de activesupport. A gema actionpack depende de activesupport 2.3.8 e rack ~> 1.1.0, enquanto a gema activemerchant depende em activesupport >= 2.3.2, braintree >= 2.0.0 e builder >= 2.0.0.
Quando as dependências forem resolvidas pela primeira vez, o Bundler selecionará activesupport 2.3.8, que satisfaz os requisitos de ambas as gems em seu Gemfile(5).
Em seguida, modifique seu Gemfile(5) para:
source 'https://rubygems.org'
gem 'actionpack', '3.0.0.rc'
gem 'activemerchant'A gem actionpack 3.0.0.rc tem várias novas dependências e atualiza a dependência activesupport para = 3.0.0.rc e a Dependência rack para ~> 1.2.1.
Quando você executa a instalação do pacote, o Bundler percebe que você alterou a gema actionpack, mas não a gema activemerchant. Ele avalia as gemas que estão sendo usadas atualmente para satisfazer seus requisitos:
também usado para satisfazer uma dependência em activemerchant, que não está sendo atualizado
não está sendo usado atualmente para satisfazer outra dependência
Como você não pediu explicitamente para atualizar o activemerchant, não esperaria que ele parasse de funcionar repentinamente após a atualização do actionpack. No entanto, satisfazer a nova dependência activesupport 3.0.0.rc do actionpack requer a atualização de uma de suas dependências.
Mesmo que activemerchant declare uma dependência muito vaga que teoricamente corresponde a activesupport 3.0.0.rc, o Bundler trata as gems em seu Gemfile(5) que não foram alteradas como uma unidade atômica em conjunto com suas dependências. Nesse caso, a dependência activemerchant é tratada como activemerchant 1.7.1 + activesupport 2.3.8, portanto, instalação do pacote informará que não pode atualizar pacote de ação.
Para atualizar explicitamente o actionpack, incluindo suas dependências das quais outras gems no Gemfile(5) ainda dependem, execute bundle update actionpack (consulte bundle update(1)).
Resumo: Em geral, depois de fazer uma alteração no Gemfile(5) , você deve primeiro tentar executar a instalação do pacote, o que garantirá que nenhuma outra gem no Gemfile( 5) é impactado pela mudança. Se isso não funcionar, execute bundle update(1) bundle-update.1.html.
Documentos de instalação do Gem http://guides.rubygems.org/rubygems-basics/#installing-gems
Documentos de assinatura do Rubygems http://guides.rubygems.org/security/