Go to main content

man pages section 1: User Commands

Exit Print View

Updated: Thursday, June 13, 2019
 
 

bundle-package (1)

Name

bundle-package - Man page for 'bundle-package' in section 1

Synopsis

Please see following description for synopsis

Description

TH  "BUNDLE-PACKAGE"  "1"  "November  2018"  "" "" SH "NAME" bun-
dle-package - Package your needed .gem files into  your  applica-
tion  SH  "SYNOPSIS"  bundle package SH "DESCRIPTION" Copy all of
the .gem files needed  to  run  the  application  into  the  ven-
dor/cache  directory.  In  the  future,  when running [bundle in-
stall(1)][bundle-install], use the gems in the cache  in  prefer-
ence  to  the ones on rubygems.org.  SH "GIT AND PATH GEMS" Since
Bundler 1.2, the bundle package command can also package :git and
:path dependencies besides .gem files. This needs to be explicit-
ly enabled via the --all option. Once used, the --all option will
be  remembered.   SH  "SUPPORT FOR MULTIPLE PLATFORMS" When using
gems  that  have  different  packages  for  different  platforms,
Bundler 1.8 and newer support caching of gems for other platforms
where the Gemfile has been resolved (i.e. present  in  the  lock-
file)   in  vendor/cache.  This  needs  to  be  enabled  via  the
--all-platforms option. This setting will be remembered  in  your
local bundler configuration.  SH "REMOTE FETCHING" By default, if
you run bundle install(1)](bundle-install.1.html)  after  running
bundle  package(1) bundle-package.1.html, bundler will still con-
nect to rubygems.org to check whether a platform-specific gem ex-
ists  for  any of the gems in vendor/cache.  P For instance, con-
sider this Gemfile(5): IP "" 4 nf

source "https://rubygems.org"

gem "nokogiri" fi IP "" 0 P If you run bundle package under C Ru-
by,  bundler will retrieve the version of nokogiri for the "ruby"
platform. If you deploy to JRuby and run bundle install,  bundler
is  forced  to  check to see whether a "java" platformed nokogiri
exists.  P Even though the nokogiri gem for the Ruby platform  is
technically  acceptable  on JRuby, it has a C extension that does
not run on JRuby. As a result, bundler will,  by  default,  still
connect  to rubygems.org to check whether it has a version of one
of your gems more specific to your platform.  P This  problem  is
also not limited to the "java" platform. A similar (common) prob-
lem can happen when developing on Windows and deploying to Linux,
or  even when developing on OSX and deploying to Linux.  P If you
know for sure that the gems packaged in vendor/cache  are  appro-
priate  for  the  platform you are on, you can run bundle install
--local to skip checking for more appropriate gems, and  use  the
ones  in  vendor/cache.   P  One way to be sure that you have the
right platformed versions of all your gems is to run bundle pack-
age  on an identical machine and check in the gems. For instance,
you can run bundle package on an  identical  staging  box  during
your  staging  process,  and check in the vendor/cache before de-
ploying to production.  P  By  default,  bundle  package(1)  bun-
dle-package.1.html  fetches and also installs the gems to the de-
fault location. To package the dependencies to vendor/cache with-
out  installing  them  to the local install location, you can run
bundle package --no-install.


See for descriptions of the following attributes:

+---------------+------------------+
|ATTRIBUTE TYPE | ATTRIBUTE VALUE  |
+---------------+------------------+
|Availability   | runtime/ruby-26  |
+---------------+------------------+
|Stability      | Uncommitted      |
+---------------+------------------+

This   software   was   built   from    source    available    at
https://github.com/oracle/solaris-userland.   The original commu-
nity   source    was    downloaded    from     http://cache.ruby-
lang.org/pub/ruby/2.6/ruby-2.6.0.tar.gz

Further  information about this software can be found on the open
source community website at http://www.ruby-lang.org/.