aboutsummaryrefslogtreecommitdiffstats
path: root/man/bundle-cache.1.txt
diff options
context:
space:
mode:
Diffstat (limited to 'man/bundle-cache.1.txt')
-rw-r--r--man/bundle-cache.1.txt78
1 files changed, 78 insertions, 0 deletions
diff --git a/man/bundle-cache.1.txt b/man/bundle-cache.1.txt
new file mode 100644
index 0000000000..b5cec05f8a
--- /dev/null
+++ b/man/bundle-cache.1.txt
@@ -0,0 +1,78 @@
+BUNDLE-CACHE(1) BUNDLE-CACHE(1)
+
+
+
+NAME
+ bundle-cache - Package your needed .gem files into your application
+
+SYNOPSIS
+ bundle cache
+
+DESCRIPTION
+ Copy all of the .gem files needed to run the application into the ven-
+ dor/cache directory. In the future, when running [bundle
+ install(1)][bundle-install], use the gems in the cache in preference to
+ the ones on rubygems.org.
+
+GIT AND PATH GEMS
+ The bundle cache command can also package :git and :path dependencies
+ besides .gem files. This needs to be explicitly enabled via the --all
+ option. Once used, the --all option will be remembered.
+
+SUPPORT FOR MULTIPLE PLATFORMS
+ When using gems that have different packages for different platforms,
+ Bundler supports caching of gems for other platforms where the Gemfile
+ has been resolved (i.e. present in the lockfile) in vendor/cache. This
+ needs to be enabled via the --all-platforms option. This setting will
+ be remembered in your local bundler configuration.
+
+REMOTE FETCHING
+ By default, if you run bundle install(1)](bundle-install.1.html) after
+ running bundle cache(1) bundle-cache.1.html, bundler will still connect
+ to rubygems.org to check whether a platform-specific gem exists for any
+ of the gems in vendor/cache.
+
+ For instance, consider this Gemfile(5):
+
+
+
+ source "https://rubygems.org"
+
+ gem "nokogiri"
+
+
+
+ If you run bundle cache under C Ruby, 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.
+
+ 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.
+
+ This problem is also not limited to the "java" platform. A similar
+ (common) problem can happen when developing on Windows and deploying to
+ Linux, or even when developing on OSX and deploying to Linux.
+
+ 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 ven-
+ dor/cache.
+
+ One way to be sure that you have the right platformed versions of all
+ your gems is to run bundle cache on an identical machine and check in
+ the gems. For instance, you can run bundle cache on an identical stag-
+ ing box during your staging process, and check in the vendor/cache
+ before deploying to production.
+
+ By default, bundle cache(1) bundle-cache.1.html fetches and also
+ installs the gems to the default location. To package the dependencies
+ to vendor/cache without installing them to the local install location,
+ you can run bundle cache --no-install.
+
+
+
+ November 2019 BUNDLE-CACHE(1)