1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
<!DOCTYPE html>
<html>
<head>
<title>Bundler: The best way to manage a Ruby application's gems</title>
<meta content='text/html; charset=UTF-8' http-equiv='Content-Type'>
<meta content='276VSYOko8B8vIu1i8i5qbj7_ql5PXo0dU69XQy-SL' name='globalsign-domain-verification'>
<link href='/images/favicon.png' rel='shortcut icon' type='image/png'>
<link href="/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" />
</head>
<body>
<div id='body'>
<div id='header'>
<a class="image" href="/"><img width="725" alt="The best way to manage your application's dependencies" src="/images/gembundler.png" /></a>
</div>
<div id='container'>
<div id='contents'>
<h2 id='faq'>
FAQ - Frequently Asked Questions
</h2>
<div class='contents'>
<div class='bullet'>
<div class='description'>
<h3>
Why Can't I Just Specify Only <code>=</code> Dependencies?
</h3>
<p>
<strong>Q:</strong> I understand the value of locking my gems down
to specific versions, but why can't I just specify <code>=</code> versions
for all my dependencies in the <code>Gemfile</code> and forget about
the <code>Gemfile.lock</code>?
</p>
<p>
<strong>A:</strong> Many of your gems will have their own
dependencies, and they are unlikely to specify <code>=</code> dependencies.
Moreover, it is probably unwise for gems to lock down all of *their*
dependencies so strictly. The <code>Gemfile.lock</code> allows you to
specify the versions of the dependencies that your application needs in
the <code>Gemfile</code>, while remembering all of the exact versions of
third-party code that your application used when it last worked correctly.
</p>
<p>
By specifying looser dependencies in your <code>Gemfile</code>
(such as <code>nokogiri ~> 1.4.2</code>), you gain the ability to run
<code>bundle update nokogiri</code>, and let bundler handle updating **only**
<code>nokogiri</code> and its dependencies to the latest version that still
satisfied the <code>~> 1.4.2</code> version requirement. This also allows you
to say "I want to use the current version of nokogiri" (<code>gem 'nokogiri'</code>
in your <code>Gemfile</code>) without having to look up the exact version number,
while still getting the benefits of ensuring that your application always runs with
exactly the same versions of all third-party code.
</p>
<h3>
Why Can't I Just Submodule Everything?
</h3>
<p>
<strong>Q:</strong> I don't understand why I need bundler to manage
my gems in this manner. Why can't I just get the gems I need and stick them
in submodules, then put each of the submodules on the load path?
</p>
<p>
<strong>A:</strong> Unfortunately, that solution requires that you
manually resolve all of the dependencies in your application, including dependencies
of dependencies. And even once you do that successfully, you would need to redo that
work if you wanted to update a particular gem. For instance, if you wanted to update
the <code>rails</code> gem, you would need to find all of the gems that depended on
dependencies of Rails (<code>rack</code>, <code>erubis</code>, <code>i18n</code>,
<code>tzinfo</code>, etc.), and find new versions that satisfy the new versions of
Rails' requirements.
</p>
<p>
Frankly, this is the sort of problem that computers are good at, and which you,
a developer, should not need to spend time doing.
</p>
<p>
More concerningly, if you made a mistake in the manual dependency resolution
process, you would not get any feedback about conflicts between different dependencies,
resulting in subtle runtime errors. For instance, if you accidentally stuck the wrong
version of <code>rack</code> in a submodule, it would likely break at runtime, when
Rails or another dependency tried to rely on a method that was not present.
</p>
<p>
<strong>
Bottom line:
</strong>
even though it might seem simpler at first glance, it is decidedly significantly
more complex.
</p>
<h3>
Why Is Bundler Downloading Gems From <code>--without</code> Groups?
</h3>
<p>
<strong>Q:</strong> I ran <code>bundle install --without production</code> and
bundler is still downloading the gems in the <code>:production</code> group. Why?
</p>
<p>
<strong>A:</strong> Bundler's <code>Gemfile.lock</code> has to contain exact
versions of all dependencies in your <code>Gemfile</code>, regardless of any options
you pass in. If it did not, deploying your application to production might change all
your dependencies, eliminating the benefit of Bundler. You could no longer be sure that
your application uses the same gems in production that you used to develop and test with.
Additionally, adding a dependency in production might result in an application that is
impossible to deploy.
</p>
<p>
For instance, imagine you have a production-only gem (let's call it
<code>rack-debugging</code>) that depends on <code>rack =1.1</code>. If we did not evaluate
the production group when you ran <code>bundle install --without production</code>, you
would deploy your application, only to receive an error that <code>rack-debugging</code>
conflicted with <code>rails </code> (which depends on <code>actionpack</code>, which depends
on <code>rack ~> 1.2.1</code>).
</p>
<p>
Another example: imagine a simple Rack application that has <code>gem 'rack'</code>
in the <code>Gemfile</code>. Again, imagine that you put <code>rack-debugging</code> in the
<code>:production</code> group. If we did not evaluate the <code>:production</code> group when
you installed via <code>bundle install --without production</code>, your app would use
<code>rack 1.2.1</code> in development, and you would learn, at deployment time, that
<code>rack-debugging</code> conflicts with the version of Rack that you tested with.
</p>
<p>
In contrast, by evaluating the gems in **all** groups when you call <code>bundle install</code>,
regardless of the groups you actually want to use in that environment, we will discover the
<code>rack-debugger</code> requirement, and install <code>rack 1.1</code>, which is also compatible
with the <code>gem 'rack'</code> requirement in your <code>Gemfile</code>.
</p>
<p>
<strong>
In short,
by always evaluating all of the dependencies in your Gemfile, regardless of the dependencies
</strong>
you intend to use in a particular environment, you avoid nasty surprises when switching to a different
set of groups in a different environment. And because we just download (but do not install) the gems,
you won't have to worry about the possibility of a difficult **installation** process for a gem that
you only use in production (or in development).
</p>
<h3>
I Have a C Extension That Requires Special Flags to Install
</h3>
<p>
<strong>Q</strong>: I have a C extension gem, such as <code>mysql</code>, which requires
special flags in order to compile and install. How can I pass these flags into the installation
process for those gems?
</p>
<p>
<strong>A</strong>: First of all, this problem does not exist for the <code>mysql2</code>
gem, which is a drop-in replacement for the <code>mysql</code> gem. In general, modern C extensions
properly discover the needed headers.
</p>
<p>
If you really need to pass flags to a C extension, you can use the <code>bundle config</code>
command:
</p>
<pre class="highlight plaintext">$ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
</pre>
<p>
Bundler will store this configuration in <code>~/.bundle/config</code>, and bundler will use
the configuration for any <code>bundle install</code> performed by the same user. As a result, once
you specify the necessary build flags for a gem, you can successfully install that gem as many times
as necessary.
</p>
<h3>
I Do Not Have an Internet Connection and Bundler Keeps Trying to Connect to the Gem Server
</h3>
<p>
<strong>Q</strong>: I do not have an internet connection but I have installed the gem before.
How do I get bundler to use my local gem cache and not connect to the gem server?
</p>
<p>
<strong>A</strong>: Use the --local flag with bundle install. The --local flag tells bundler
to use the local gem cache instead of reaching out to the remote gem server.
</p>
<pre class="highlight plaintext">$ bundle install --local
</pre>
<h3>
Bundling From RubyGems is Really Slow
</h3>
<p>
<strong>Q</strong>: When I bundle from rubygems it is really slow. Is there anything I can do to make it faster?
</p>
<p>
<strong>A</strong>: Add the --full-index flag when bundling from the rubygems server. This downloads
the index all at once instead of making numerous small requests to the api.
</p>
<pre class="highlight plaintext">$ bundle install --full-index</pre>
</div>
</div>
</div>
</div>
</div>
</div>
<div id='footer'>
<img src="/images/emocow.png" />
<img src="/images/panda.jpg" />
<div class='spacer'></div>
<div id='credits'>
<p>
Many thanks to Bundler's <a href="/contributors.html">contributors</a>
and <a href="/sponsors.html">sponsors</a>
</p>
</div>
<div class='spacer'></div>
<img src="/images/bundler-small.png" />
</div>
<a href='http://github.com/bundler/bundler/' id='github'>
<img alt='Fork me on GitHub' src='http://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png'>
</a>
<div id='prod-versions'>
Docs:
<a href="/v0.9/">v0.9</a>
<a href="/v1.0/">v1.0</a>
<a href="/v1.1/">v1.1</a>
<a href="/v1.2/">v1.2</a>
<a href="/v1.3/">v1.3</a>
<a class="current" href="/v1.5/index.html">v1.5</a>
<a href="/">v1.6</a>
</div>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-39559982-1', 'bundler.io');
ga('send', 'pageview');
</script>
</body>
</html>
|
