1GEMFILE(5) GEMFILE(5)
2
6 Gemfile - A format for describing gem dependencies for Ruby programs
7
9 A Gemfile describes the gem dependencies required to execute associated
10 Ruby code.
11 Place the Gemfile in the root of the directory containing the associ‐
13 ated code. For instance, in a Rails application, place the Gemfile in
14 the same directory as the Rakefile.
15
17 A Gemfile is evaluated as Ruby code, in a context which makes available
18 a number of methods used to describe the gem requirements.
19
21 At the top of the Gemfile, add a line for the Rubygems source that con‐
22 tains the gems listed in the Gemfile.
23 source "https://rubygems.org"
27 It is possible, but not recommended as of Bundler 1.7, to add multiple
31 global source lines. Each of these sources MUST be a valid Rubygems
32 repository.
33 Sources are checked for gems following the heuristics described in
35 SOURCE PRIORITY. If a gem is found in more than one global source,
36 Bundler will print a warning after installing the gem indicating which
37 source was used, and listing the other sources where the gem is avail‐
38 able. A specific source can be selected for gems that need to use a
39 non-standard repository, suppressing this warning, by using the :source
40 option or a source block.
41 CREDENTIALS
43 Some gem sources require a username and password. Use [bundle con‐
44 fig(1)][bundle-config] to set the username and password for any of the
45 sources that need it. The command must be run once on each computer
46 that will install the Gemfile, but this keeps the credentials from
47 being stored in plain text in version control.
48 bundle config gems.example.com user:password
52 For some sources, like a company Gemfury account, it may be easier to
56 include the credentials in the Gemfile as part of the source URL.
57 source "https://user:password@gems.example.com"
61 Credentials in the source URL will take precedence over credentials set
65 using config.
66
68 If your application requires a specific Ruby version or engine, specify
69 your requirements using the ruby method, with the following arguments.
70 All parameters are OPTIONAL unless otherwise specified.
71 VERSION (required)
73 The version of Ruby that your application requires. If your application
74 requires an alternate Ruby engine, such as JRuby or Rubinius, this
75 should be the Ruby version that the engine is compatible with.
76 ruby "1.9.3"
80 ENGINE
84 Each application may specify a Ruby engine. If an engine is specified,
85 an engine version must also be specified.
86 What exactly is an Engine? - A Ruby engine is an implementation of the
88 Ruby language.
89 · For background: the reference or original implementation of the
91 Ruby programming language is called Matz´s Ruby Interpreter
92 https://en.wikipedia.org/wiki/Ruby_MRI, or MRI for short. This is
93 named after Ruby creator Yukihiro Matsumoto, also known as Matz.
94 MRI is also known as CRuby, because it is written in C. MRI is the
95 most widely used Ruby engine.
96 · Other implementations https://www.ruby-lang.org/en/about/ of Ruby
98 exist. Some of the more well-known implementations include Rubinius
99 https://rubinius.com/, and JRuby http://jruby.org/. Rubinius is an
100 alternative implementation of Ruby written in Ruby. JRuby is an
101 implementation of Ruby on the JVM, short for Java Virtual Machine.
102 ENGINE VERSION
106 Each application may specify a Ruby engine version. If an engine ver‐
107 sion is specified, an engine must also be specified. If the engine is
108 "ruby" the engine version specified must match the Ruby version.
109 ruby "1.8.7", :engine => "jruby", :engine_version => "1.6.7"
113 PATCHLEVEL
117 Each application may specify a Ruby patchlevel.
118 ruby "2.0.0", :patchlevel => "247"
122
126 Specify gem requirements using the gem method, with the following argu‐
127 ments. All parameters are OPTIONAL unless otherwise specified.
128 NAME (required)
130 For each gem requirement, list a single gem line.
131 gem "nokogiri"
135 VERSION
139 Each gem MAY have one or more version specifiers.
140 gem "nokogiri", ">= 1.4.2"
144 gem "RedCloth", ">= 4.1.0", "< 4.2.0"
145 REQUIRE AS
149 Each gem MAY specify files that should be used when autorequiring via
150 Bundler.require. You may pass an array with multiple files or true if
151 file you want required has same name as gem or false to prevent any
152 file from being autorequired.
153 gem "redis", :require => ["redis/connection/hiredis", "redis"]
157 gem "webmock", :require => false
158 gem "debugger", :require => true
159 The argument defaults to the name of the gem. For example, these are
163 identical:
164 gem "nokogiri"
168 gem "nokogiri", :require => "nokogiri"
169 gem "nokogiri", :require => true
170 GROUPS
174 Each gem MAY specify membership in one or more groups. Any gem that
175 does not specify membership in any group is placed in the default
176 group.
177 gem "rspec", :group => :test
181 gem "wirble", :groups => [:development, :test]
182 The Bundler runtime allows its two main methods, Bundler.setup and
186 Bundler.require, to limit their impact to particular groups.
187 # setup adds gems to Ruby´s load path
191 Bundler.setup # defaults to all groups
192 require "bundler/setup" # same as Bundler.setup
193 Bundler.setup(:default) # only set up the _default_ group
194 Bundler.setup(:test) # only set up the _test_ group (but `not` _default_)
195 Bundler.setup(:default, :test) # set up the _default_ and _test_ groups, but no others
196 # require requires all of the gems in the specified groups
198 Bundler.require # defaults to the _default_ group
199 Bundler.require(:default) # identical
200 Bundler.require(:default, :test) # requires the _default_ and _test_ groups
201 Bundler.require(:test) # requires the _test_ group
202 The Bundler CLI allows you to specify a list of groups whose gems bun‐
206 dle install should not install with the --without option. To specify
207 multiple groups to ignore, specify a list of groups separated by spa‐
208 ces.
209 bundle install --without test
213 bundle install --without development test
214 After running bundle install --without test, bundler will remember that
218 you excluded the test group in the last installation. The next time you
219 run bundle install, without any --without option, bundler will recall
220 it.
221 Also, calling Bundler.setup with no parameters, or calling require
223 "bundler/setup" will setup all groups except for the ones you excluded
224 via --without (since they are not available).
225 Note that on bundle install, bundler downloads and evaluates all gems,
227 in order to create a single canonical list of all of the required gems
228 and their dependencies. This means that you cannot list different ver‐
229 sions of the same gems in different groups. For more details, see
230 Understanding Bundler http://bundler.io/rationale.html.
231 PLATFORMS
233 If a gem should only be used in a particular platform or set of plat‐
234 forms, you can specify them. Platforms are essentially identical to
235 groups, except that you do not need to use the --without install-time
236 flag to exclude groups of gems for other platforms.
237 There are a number of Gemfile platforms:
239 ruby C Ruby (MRI) or Rubinius, but NOT Windows
241 mri Same as ruby, but not Rubinius
243 mingw Windows 32 bit ´mingw32´ platform (aka RubyInstaller)
245 x64_mingw
247 Windows 64 bit ´mingw32´ platform (aka RubyInstaller x64)
248 rbx Same as ruby, but only Rubinius (not MRI)
250 jruby JRuby
252 mswin Windows
254 You can restrict further by platform and version for all platforms
256 except for rbx, jruby, and mswin.
257 To specify a version in addition to a platform, append the version num‐
259 ber without the delimiter to the platform. For example, to specify that
260 a gem should only be used on platforms with Ruby 2.3, use:
261 ruby_23
265 The full list of platforms and supported versions includes:
269 ruby 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5
271 mri 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5
273 mingw 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5
275 x64_mingw
277 2.0, 2.1, 2.2, 2.3, 2.4, 2.5
278 As with groups, you can specify one or more platforms:
280 gem "weakling", :platforms => :jruby
284 gem "ruby-debug", :platforms => :mri_18
285 gem "nokogiri", :platforms => [:mri_18, :jruby]
286 All operations involving groups (bundle install, Bundler.setup,
290 Bundler.require) behave exactly the same as if any groups not matching
291 the current platform were explicitly excluded.
292 SOURCE
294 You can select an alternate Rubygems repository for a gem using the
295 ´:source´ option.
296 gem "some_internal_gem", :source => "https://gems.example.com"
300 This forces the gem to be loaded from this source and ignores any
304 global sources declared at the top level of the file. If the gem does
305 not exist in this source, it will not be installed.
306 Bundler will search for child dependencies of this gem by first looking
308 in the source selected for the parent, but if they are not found there,
309 it will fall back on global sources using the ordering described in
310 SOURCE PRIORITY.
311 Selecting a specific source repository this way also suppresses the
313 ambiguous gem warning described above in GLOBAL SOURCES (#source).
314 GIT
316 If necessary, you can specify that a gem is located at a particular git
317 repository using the :git parameter. The repository can be accessed via
318 several protocols:
319 HTTP(S)
321 gem "rails", :git => "https://github.com/rails/rails.git"
322 SSH gem "rails", :git => "git@github.com:rails/rails.git"
324 git gem "rails", :git => "git://github.com/rails/rails.git"
326 If using SSH, the user that you use to run bundle install MUST have the
328 appropriate keys available in their $HOME/.ssh.
329 NOTE: http:// and git:// URLs should be avoided if at all possible.
331 These protocols are unauthenticated, so a man-in-the-middle attacker
332 can deliver malicious code and compromise your system. HTTPS and SSH
333 are strongly preferred.
334 The group, platforms, and require options are available and behave
336 exactly the same as they would for a normal gem.
337 A git repository SHOULD have at least one file, at the root of the
339 directory containing the gem, with the extension .gemspec. This file
340 MUST contain a valid gem specification, as expected by the gem build
341 command.
342 If a git repository does not have a .gemspec, bundler will attempt to
344 create one, but it will not contain any dependencies, executables, or C
345 extension compilation instructions. As a result, it may fail to prop‐
346 erly integrate into your application.
347 If a git repository does have a .gemspec for the gem you attached it
349 to, a version specifier, if provided, means that the git repository is
350 only valid if the .gemspec specifies a version matching the version
351 specifier. If not, bundler will print a warning.
352 gem "rails", "2.3.8", :git => "https://github.com/rails/rails.git"
356 # bundle install will fail, because the .gemspec in the rails
357 # repository´s master branch specifies version 3.0.0
358 If a git repository does not have a .gemspec for the gem you attached
362 it to, a version specifier MUST be provided. Bundler will use this ver‐
363 sion in the simple .gemspec it creates.
364 Git repositories support a number of additional options.
366 branch, tag, and ref
368 You MUST only specify at most one of these options. The default
369 is :branch => "master"
370 For example:
372 git "https://github.com/rails/rails.git", :branch => "5-0-sta‐
374 ble" do
375 git "https://github.com/rails/rails.git", :tag => "v5.0.0" do
377 git "https://github.com/rails/rails.git", :ref => "4aded" do
379 submodules
381 For reference, a git submodule
382 https://git-scm.com/book/en/v2/Git-Tools-Submodules lets you
383 have another git repository within a subfolder of your reposi‐
384 tory. Specify :submodules => true to cause bundler to expand any
385 submodules included in the git repository
386 If a git repository contains multiple .gemspecs, each .gemspec repre‐
388 sents a gem located at the same place in the file system as the .gem‐
389 spec.
390 |~rails [git root]
394 | |-rails.gemspec [rails gem located here]
395 |~actionpack
396 | |-actionpack.gemspec [actionpack gem located here]
397 |~activesupport
398 | |-activesupport.gemspec [activesupport gem located here]
399 |...
400 To install a gem located in a git repository, bundler changes to the
404 directory containing the gemspec, runs gem build name.gemspec and then
405 installs the resulting gem. The gem build command, which comes standard
406 with Rubygems, evaluates the .gemspec in the context of the directory
407 in which it is located.
408 GIT SOURCE
410 A custom git source can be defined via the git_source method. Provide
411 the source´s name as an argument, and a block which receives a single
412 argument and interpolates it into a string to return the full repo
413 address:
414 git_source(:stash){ |repo_name| "https://stash.corp.acme.pl/#{repo_name}.git" }
418 gem ´rails´, :stash => ´forks/rails´
419 In addition, if you wish to choose a specific branch:
423 gem "rails", :stash => "forks/rails", :branch => "branch_name"
427 GITHUB
431 NOTE: This shorthand should be avoided until Bundler 2.0, since it cur‐
432 rently expands to an insecure git:// URL. This allows a man-in-the-mid‐
433 dle attacker to compromise your system.
434 If the git repository you want to use is hosted on GitHub and is pub‐
436 lic, you can use the :github shorthand to specify the github username
437 and repository name (without the trailing ".git"), separated by a
438 slash. If both the username and repository name are the same, you can
439 omit one.
440 gem "rails", :github => "rails/rails"
444 gem "rails", :github => "rails"
445 Are both equivalent to
449 gem "rails", :git => "git://github.com/rails/rails.git"
453 Since the github method is a specialization of git_source, it accepts a
457 :branch named argument.
458 GIST
460 If the git repository you want to use is hosted as a Github Gist and is
461 public, you can use the :gist shorthand to specify the gist identifier
462 (without the trailing ".git").
463 gem "the_hatch", :gist => "4815162342"
467 Is equivalent to:
471 gem "the_hatch", :git => "https://gist.github.com/4815162342.git"
475 Since the gist method is a specialization of git_source, it accepts a
479 :branch named argument.
480 BITBUCKET
482 If the git repository you want to use is hosted on Bitbucket and is
483 public, you can use the :bitbucket shorthand to specify the bitbucket
484 username and repository name (without the trailing ".git"), separated
485 by a slash. If both the username and repository name are the same, you
486 can omit one.
487 gem "rails", :bitbucket => "rails/rails"
491 gem "rails", :bitbucket => "rails"
492 Are both equivalent to
496 gem "rails", :git => "https://rails@bitbucket.org/rails/rails.git"
500 Since the bitbucket method is a specialization of git_source, it
504 accepts a :branch named argument.
505 PATH
507 You can specify that a gem is located in a particular location on the
508 file system. Relative paths are resolved relative to the directory con‐
509 taining the Gemfile.
510 Similar to the semantics of the :git option, the :path option requires
512 that the directory in question either contains a .gemspec for the gem,
513 or that you specify an explicit version that bundler should use.
514 Unlike :git, bundler does not compile C extensions for gems specified
516 as paths.
517 gem "rails", :path => "vendor/rails"
521 If you would like to use multiple local gems directly from the filesys‐
525 tem, you can set a global path option to the path containing the gem´s
526 files. This will automatically load gemspec files from subdirectories.
527 path ´components´ do
531 gem ´admin_ui´
532 gem ´public_ui´
533 end
534
538 The :source, :git, :path, :group, and :platforms options may be applied
539 to a group of gems by using block form.
540 source "https://gems.example.com" do
544 gem "some_internal_gem"
545 gem "another_internal_gem"
546 end
547 git "https://github.com/rails/rails.git" do
549 gem "activesupport"
550 gem "actionpack"
551 end
552 platforms :ruby do
554 gem "ruby-debug"
555 gem "sqlite3"
556 end
557 group :development, :optional => true do
559 gem "wirble"
560 gem "faker"
561 end
562 In the case of the group block form the :optional option can be given
566 to prevent a group from being installed unless listed in the --with
567 option given to the bundle install command.
568 In the case of the git block form, the :ref, :branch, :tag, and :sub‐
570 modules options may be passed to the git method, and all gems in the
571 block will inherit those options.
572
574 The install_if method allows gems to be installed based on a proc or
575 lambda. This is especially useful for optional gems that can only be
576 used if certain software is installed or some other conditions are met.
577 install_if -> { RUBY_PLATFORM =~ /darwin/ } do
581 gem "pasteboard"
582 end
583
587 The .gemspec http://guides.rubygems.org/specification-reference/ file
588 is where you provide metadata about your gem to Rubygems. Some required
589 Gemspec attributes include the name, description, and homepage of your
590 gem. This is also where you specify the dependencies your gem needs to
591 run.
592 If you wish to use Bundler to help install dependencies for a gem while
594 it is being developed, use the gemspec method to pull in the dependen‐
595 cies listed in the .gemspec file.
596 The gemspec method adds any runtime dependencies as gem requirements in
598 the default group. It also adds development dependencies as gem
599 requirements in the development group. Finally, it adds a gem require‐
600 ment on your project (:path => ´.´). In conjunction with Bundler.setup,
601 this allows you to require project files in your test code as you would
602 if the project were installed as a gem; you need not manipulate the
603 load path manually or require project files via relative paths.
604 The gemspec method supports optional :path, :glob, :name, and :develop‐
606 ment_group options, which control where bundler looks for the .gemspec,
607 the glob it uses to look for the gemspec (defaults to: "{,,/*}.gem‐
608 spec"), what named .gemspec it uses (if more than one is present), and
609 which group development dependencies are included in.
610 When a gemspec dependency encounters version conflicts during resolu‐
612 tion, the local version under development will always be selected --
613 even if there are remote versions that better match other requirements
614 for the gemspec gem.
615
617 When attempting to locate a gem to satisfy a gem requirement, bundler
618 uses the following priority order:
619 1. The source explicitly attached to the gem (using :source, :path, or
621 :git)
622 2. For implicit gems (dependencies of explicit gems), any source, git,
624 or path repository declared on the parent. This results in bundler
625 prioritizing the ActiveSupport gem from the Rails git repository
626 over ones from rubygems.org
627 3. The sources specified via global source lines, searching each
629 source in your Gemfile from last added to first added.
630 July 2017 GEMFILE(5)