You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
--- source/v1.12/bundler_setup.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/bundler_setup.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,78 +1,103 @@
---
-title: Bundler setup-description: Configure the load path so all dependencies in your Gemfile can be required+title: Using Bundler with plain Ruby
---
+.container.guide+ %h2 Bundler.setup-## Bundler.setup-+ .contents+ .bullet+ .description
Configure the load path so all dependencies in
your Gemfile can be required
--~~~ ruby+ :code+ # lang: ruby
require 'rubygems'
require 'bundler/setup'
require 'nokogiri'
-~~~+ .bullet+ .description
Only add gems from specified groups to the
load path. If you want the gems in the
default group, make sure to include it
--~~~ ruby+ :code+ # lang: ruby
require 'rubygems'
require 'bundler'
Bundler.setup(:default, :ci)
require 'nokogiri'
-~~~--<a href="/groups.html" class="btn btn-primary">Learn More: Groups</a>+ = link_to 'Learn More: Groups', './groups.html', class: 'btn btn-primary'-## Compatibility+ %h2 Compatibility+ .contents+ .bullet+ .description
Ruby 2.0 and RubyGems 2.0 both require Bundler 1.3 or later. If you have questions about compatibility between Bundler and your system, please check the compatibility list.
+ = link_to 'Learn More: Compatibility', '/compatibility.html', class: 'btn btn-primary'-<a href="/compatibility.html" class="btn btn-primary">Learn More: Compatibility</a>--## Setting Up Your Application to Use Bundler+ %h2#setting-up-your-application-to-use-bundler+ Setting Up Your Application to Use Bundler+ .bullet+ .description
Bundler makes sure that Ruby can find all of the gems in the <code>Gemfile</code>
-(and all of their dependencies). If your app is a Rails 3 app, your default application-already has the code necessary to invoke bundler. If it is a Rails 2.3 app, please see:-<a href="./rails23.html">Setting up Bundler in Rails 2.3</a>+ (and all of their dependencies). If your app is a Rails app, your default application+ already has the code necessary to invoke bundler.+ .bullet+ .description
For another kind of application (such as a Sinatra application), you will need to set up
bundler before trying to require any gems. At the top of the first file that your
application loads (for Sinatra, the file that calls <code>require 'sinatra'</code>), put
the following code:
-~~~ ruby+ :code+ # lang: ruby
require 'rubygems'
require 'bundler/setup'
-~~~+ .bullet+ .description
This will automatically discover your <code>Gemfile</code>, and make all of the gems in
your <code>Gemfile</code> available to Ruby (in technical terms, it puts the gems "on the
load path"). You can think of it as an adding some extra powers to <code>require
'rubygems'</code>.
+ .bullet+ .description
Now that your code is available to Ruby, you can require the gems that you need. For
instance, you can <code>require 'sinatra'</code>. If you have a lot of dependencies, you
might want to say "require all of the gems in my <code>Gemfile</code>". To do this, put
the following code immediately following <code>require 'bundler/setup'</code>:
-~~~ ruby+ :code+ # lang: ruby
Bundler.require(:default)
-~~~-
For our example Gemfile, this line is exactly equivalent to:
-~~~ ruby+ :code+ # lang: ruby
require 'rails'
require 'rack-cache'
require 'nokogiri'
-~~~-+ .bullet+ .description+ Astute readers will notice that the correct way to require the <code>rack-cache</code>+ gem is <code>require 'rack/cache'</code>, not <code>require 'rack-cache'</code>. To tell+ bundler to use <code>require 'rack/cache'</code>, update your Gemfile:++ :code+ # lang: ruby+ source 'https://rubygems.org'++ gem 'rails', '5.0.0'+ gem 'rack-cache', :require => 'rack/cache'+ gem 'nokogiri', '~> 1.4.2'+ .bullet+ .description
For such a small <code>Gemfile</code>, we'd advise you to skip
-<code>Bundler.require</code> and just require the gems by hand. For much+ <code>Bundler.require</code> and just require the gems by hand (especially given the+ need to put in a <code>:require</code> directive in the <code>Gemfile</code>). For much
larger <code>Gemfile</code>s, using <code>Bundler.require</code> allows you to skip
repeating a large stack of requirements.
bundler_sharing
--- source/v1.12/bundler_sharing.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/bundler_sharing.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,12 +1,16 @@
---
-title: Sharing-description: How to share an application with Bundler+title: Sharing your code
---
+.container.guide+ %h2#sharing+ Sharing your code+ .contents+ .bullet+ .description+ %h3#checking-your-code-into-version-control+ Checking Your Code into Version Control-## Sharing--### Checking Your Code into Version Control-+ %p
After developing your application for a while, check in the application together with the
<code>Gemfile</code> and <code>Gemfile.lock</code> snapshot. Now, your repository has a
record of the exact versions of all of the gems that you used the last time you know for
@@ -15,27 +19,34 @@
depends on dozens of gems, once you take into consideration all of the implicit
requirements of the gems you depend on.
+ %p.description
This is important: <strong>the <code>Gemfile.lock</code> makes your application a single
package of both your own code and the third-party code it ran the last time you know for
sure that everything worked</strong>. Specifying exact versions of the third-party code
you depend on in your <code>Gemfile</code> would not provide the same guarantee, because
gems usually declare a range of versions for their dependencies.
+ %p.description
The next time you run <code>bundle install</code> on the same machine, bundler will see
that it already has all of the dependencies you need, and skip the installation process.
+ %p.description
Do not check in the <code>.bundle</code> directory, or any of the files inside it. Those
files are specific to each particular machine, and are used to persist installation options
between runs of the <code>bundle install</code> command.
+ %p.description
If you have run <code>bundle pack</code>, the gems (although not the git gems) required
by your bundle will be downloaded into <code>vendor/cache</code>. Bundler can run without
connecting to the internet (or the RubyGems server) if all the gems you need are present
in that folder and checked in to your source control. This is an <strong>optional</strong>
step, and not recommended, due to the increase in size of your source control repository.
-### Sharing Your Application With Other Developers+ .bullet+ %h3#sharing-your-application-with-other-developers+ Sharing Your Application With Other Developers+ %p.description
When your co-developers (or you on another machine) check out your code, it will come
with the exact versions of all the third-party code your application used on the machine
that you last developed on (in the <code>Gemfile.lock</code>). When **they** run
@@ -43,6 +54,7 @@
the dependency resolution step. Instead, it will install all of the same gems that you
used on the original machine.
+ %p.description
In other words, you don't have to guess which versions of the dependencies you should
install. In the example we've been using, even though <code>rack-cache</code> declares a
dependency on <code>rack >= 0.4</code>, we know for sure it works with <code>rack
deploying
--- source/v1.12/deploying.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/deploying.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,100 +1,106 @@
---
-title: Deploying bundled applications+title: Deploying with Bundler
---
---## Deploying bundled applications-+.container.guide+ %h2 Deploying bundled applications+ .contents+ .bullet+ .description
Before deploying an app that uses Bundler, Add your <code>Gemfile</code>
and <code>Gemfile.lock</code> to source control, but ignore the
<code>.bundle</code> folder, which is specific to each machine.
-+ :code
$ echo ".bundle" >> .gitignore
$ git add Gemfile Gemfile.lock .gitignore
$ git commit -m "Add Bundler support"
-+ .notes
Once you have done that, there are two ways to deploy using Bundler:
manually or automatically.
-### Manual deployment-+ .bullet+ .description+ %h3 Manual deployment
In your deploy script, after updating to the latest
code, install your bundle to the <code>vendor/bundle</code>
directory, ensuring all your dependencies are met.
-+ :code
$ bundle install --deployment
-+ .notes+ %p
Start your application servers as usual, and your
application will use your bundled environment
with the exact same gems you use in development.
+ %p
If you have run <code>bundle package</code>, the cached
gems will be used automatically.
-<a href="/man/bundle-cache.1.html" class="btn btn-primary">Learn More: Packing</a>--### Automatic deployment with Capistrano+ = link_to 'Learn More: Packing', '/man/bundle-cache.1.html', class: 'btn btn-primary'+ .bullet+ %h3 Automatic deployment with Capistrano+ .description
To pull in the Bundler Cap task, just add this to your
<code>deploy.rb</code> file:
--~~~ ruby+ :code+ # lang: ruby
require 'bundler/capistrano'
-~~~-+ .notes
That's it! Running <code>cap deploy</code> will now automatically run
<code>bundle install</code> on the remote server with deployment-friendly
options. A list of options that can be changed is available in the help
for the cap task. To see it, run <code>cap -e bundle:install</code>.
-### Automatic deployment with Vlad-+ .bullet+ .description+ %h3 Automatic deployment with Vlad
There is a default Vlad task available. To make it available, add this line
to the Vlad <code>deploy.rb</code>.
--~~~ ruby+ :code+ # lang: ruby
require 'bundler/vlad'
-~~~-+ .notes
Once you have done that, the <code>vlad:bundle:install</code> task will be
available for use. Make sure it is run as part of your deploy. For example:
--~~~ ruby+ :code+ # lang: ruby
task "vlad:deploy" => %w[
vlad:update vlad:bundle:install vlad:start_app vlad:cleanup
]
-~~~--### After deploying+ .bullet+ .description+ %h3 After deploying
Make sure to use <code>bundle exec</code> to run any executables
from gems in the bundle
-+ :code
$ bundle exec rake db:setup
-+ .notes
Alternatively, you can use the <code>--binstubs</code> option on the
install command to generate executable binaries that can be used instead of
<code>bundle exec</code>.
+ = link_to 'Learn More: Executables', '/man/bundle-exec.1.html', class: 'btn btn-primary'-<a href="/man/bundle-exec.1.html" class="btn btn-primary">Learn More: Executables</a>---### Heroku-+ .bullet+ .description+ %h3 Heroku
When you deploy to Heroku, Bundler will be run automatically as long as a Gemfile is present. If you check in your Gemfile.lock, Heroku will run <code>`bundle install --deployment`</code>. If you want to exclude certain groups using the <code>--without</code> option, you need to use <code>`heroku config`</code>.
+ :code+ $ heroku config:set BUNDLE_WITHOUT="test development" --app app_name+ = link_to 'Heroku Bundler Documentation', 'http://docs.heroku.com/bundler', class: 'btn btn-primary'- $ heroku config:add BUNDLE_WITHOUT="test development" --app app_name--<a href="http://docs.heroku.com/bundler" class="btn btn-primary">Heroku Bundler Documentation</a>--## Deploying Your Application+ %h2#deploying-your-application+ Deploying Your Application+ .bullet+ .description
When you run <code>bundle install</code>, bundler will (by default), install your gems
to your system repository of gems. This means that they will show up in <code>gem
list</code>. Additionally, if you are developing a number of applications, you will not
need to download and install gems in common for each application. This is nice for
development, but somewhat problematic for deployment.
+ %p.description
In a deployment scenario, the Unix user you deploy with may not have access to install
gems to a system location. Even if the user does (or you use <code>sudo</code>), the
user that boots the application may not have access to them. For instance, Passenger
@@ -103,40 +109,47 @@
(even at the cost of a somewhat slower deploy-time <code>bundle install</code> when some
third-party dependencies have changed).
+ %p.description
As a result, bundler comes with a <code>--deployment</code> flag that encapsulates the
best practices for using bundler in a deployment environment. These practices are based
on significant feedback we have received during the development of bundler, as well as a
number of bug reports that mostly reflected a misunderstanding of how to best configure
bundler for deployment. The <code>--deployment</code> flags adds the following defaults:
-* Instead of installing gems to the system location, bundler will install gems to+ .description+ %ul+ %li+ Instead of installing gems to the system location, bundler will install gems to
<code>vendor/bundle</code> inside your application. Bundler will transparently remember
this location when you invoke it inside your application (with
<code>Bundler.setup</code> and <code>Bundler.require</code>).
--* Bundler will not use gems already installed to your system, even if they exist.--* If you have run <code>bundle pack</code>, checked in the <code>vendor/cache</code>+ %li+ Bundler will not use gems already installed to your system, even if they exist.+ %li+ If you have run <code>bundle pack</code>, checked in the <code>vendor/cache</code>
directory, and do not have any git gems, Bundler will not contact the internet while
installing your bundle.
--* Bundler will require a <code>Gemfile.lock</code> snapshot, and fail if you did not+ %li+ Bundler will require a <code>Gemfile.lock</code> snapshot, and fail if you did not
provide one.
--* Bundler will not transparently update your <code>Gemfile.lock</code> if it is out of+ %li+ Bundler will not transparently update your <code>Gemfile.lock</code> if it is out of
date with your <code>Gemfile</code>
+ %p.description
If you use Capistrano, you should symlink <code>vendor/bundle</code> to
<code>shared/vendor_bundle</code> so that bundler will share your installed gems between
deployments (making things zippy if you didn't make any changes), but still give you the
benefits of isolation from other applications.
+ %p.description
By defaulting the bundle directory to <code>vendor/bundle</code>, and installing your
bundle as part of your deployment process, you can be sure that the same Unix user that
checked out your application also installed the third-party code your application needs.
This means that if Passenger (or Unicorn) can see your application, it can also see its
dependencies.
+ %p.description
The <code>--deployment</code> flag requires an up-to-date <code>Gemfile.lock</code> to
ensure that the testing you have done (in development and staging) actually reflects the
code you put into production. You can run <code>bundle check</code> before deploying
faq
--- source/v1.12/faq.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/faq.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,16 +1,21 @@
---
-title: FAQ - Frequently Asked Questions+title: Frequently Asked Questions
---
--## FAQ - Frequently Asked Questions--### Why Can't I Just Specify Only <code>=</code> Dependencies?-+.container.guide+ %h2#faq+ Frequently Asked Questions+ .contents+ .bullet+ .description+ %h3+ Why Can't I Just Specify Only <code>=</code> Dependencies?+ %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
<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*
@@ -19,6 +24,7 @@
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
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**
@@ -29,12 +35,15 @@
while still getting the benefits of ensuring that your application always runs with
exactly the same versions of all third-party code.
-### Why Can't I Just Submodule Everything?+ %h3+ Why Can't I Just Submodule Everything?+ %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
<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
@@ -44,23 +53,32 @@
<code>tzinfo</code>, etc.), and find new versions that satisfy the new versions of
Rails' requirements.
+ %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
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.
-<strong>Bottom line:</strong> even though it might seem simpler at first glance, it is decidedly significantly+ %p+ %strong+ Bottom line:++ even though it might seem simpler at first glance, it is decidedly significantly
more complex.
-### Why Is Bundler Downloading Gems From <code>--without</code> Groups?+ %h3+ Why Is Bundler Downloading Gems From <code>--without</code> Groups?+ %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
<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
@@ -69,6 +87,7 @@
Additionally, adding a dependency in production might result in an application that is
impossible to deploy.
+ %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
@@ -76,6 +95,7 @@
conflicted with <code>rails </code> (which depends on <code>actionpack</code>, which depends
on <code>rack ~> 1.2.1</code>).
+ %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
@@ -83,59 +103,67 @@
<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
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>.
-<strong>In short,</strong>+ %p+ %strong+ In short,
by always evaluating all of the dependencies in your Gemfile, regardless of the dependencies
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).
-### I Have a C Extension That Requires Special Flags to Install+ %h3+ I Have a C Extension That Requires Special Flags to Install+ %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
<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
If you really need to pass flags to a C extension, you can use the <code>bundle config</code>
command:
+ :code
$ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
-+ %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.
-### I Do Not Have an Internet Connection and Bundler Keeps Trying to Connect to the Gem Server-+ %h3+ I Do Not Have an Internet Connection and Bundler Keeps Trying to Connect to the Gem Server+ %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
<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.
+ :code
$ bundle install --local
+ %h3+ Bundling From RubyGems is Really Slow-### Bundling From RubyGems is Really Slow-+ %p
<strong>Q</strong>: When I bundle from rubygems it is really slow. Is there anything I can do to make it faster?
+ %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.
+ :code
$ bundle install --full-index
--### `Gemfile.lock` Breaks `git bisect`--<strong>Q</strong>: How to run `git bisect` correctly?--<strong>A</strong>: Read [Git Bisect Guide](/git_bisect.html)
git_bisect
--- source/v1.12/git_bisect.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/git_bisect.html.md 2022-07-08 07:52:54.000000000 +0000@@ -2,6 +2,12 @@
title: How to git bisect in projects using Bundler
---
+## How to use git bisect++[`git bisect`](https://git-scm.com/docs/git-bisect) is a useful debugging tool. For context, `git bisect` is a git command that can be used to track down the specific commit which a bug was introduced into the codebase.++If you can find a commit where the code works properly and a commit with the offending bug, you don’t have to trace down the buggy commit by hand. The `git bisect` command, via binary search, will help you find the offending commit. For example, the Git documentation has [a handy `git bisect` guide](https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git) that shows two ways to use it.+
## How to git bisect in projects using Bundler
A few things that may not be obvious are needed for `git bisect` to work
git
--- source/v1.12/git.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/git.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,128 +1,130 @@
---
title: Gems from git repositories
-description: How to use gems directly from git
---
+.container.guide+ %h2 Gems from git repositories-## Gems from git repositories--Bundler adds the ability to use gems directly from git repositories. Setting-them up is as easy as adding a gem to your Gemfile. Using the very latest-version of a gem (or even a fork) is just as easy as using an official-release.--Because RubyGems lacks the ability to handle gems from git, any gems+ .contents+ .bullet+ .description+ %p+ Bundler has the ability to install gems directly from git repositories. Installing+ a gem using git is as easy as adding a gem to your Gemfile.+ %p+ Note that because RubyGems lacks the ability to handle gems from git, any gems
installed from a git repository will not show up in <code>gem list</code>.
They will, however, be available after running <code>Bundler.setup</code>.
+ .bullet+ .description
Specify that a gem should come from a git
repository with a .gemspec at its root
--~~~ ruby-gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git'-~~~-+ :code+ # lang: ruby+ gem 'rack', :git => 'https://github.com/rack/rack'+ .bullet+ .description
If there is no .gemspec at the root of
a git repository, you must specify a version
that bundler should use when resolving
dependencies
--~~~ ruby-gem 'deep_merge', '1.0', :git => 'https://github.com/peritor/deep_merge.git'-~~~-+ :code+ # lang: ruby+ gem 'nokogiri', '1.7.0.1', :git => 'https://github.com/sparklemotion/nokogiri'+ .bullet+ .description
Specify that a git repository containing
multiple .gemspec files should be treated
as a gem source
--~~~ ruby+ :code+ # lang: ruby
git 'https://github.com/rails/rails.git' do
gem 'railties'
- gem 'action_pack'- gem 'active_model'+ gem 'actionpack'+ gem 'activemodel'
end
-~~~--Specify that a git repository should use-a particular ref, branch, or tag--~~~ ruby-:git => 'https://github.com/rails/rails.git', :ref => '4aded'-:git => 'https://github.com/rails/rails.git', :branch => '2-3-stable'-:git => 'https://github.com/rails/rails.git', :tag => 'v2.3.5'-~~~-+ .bullet+ .description+ From the previous example, you may specify a particular ref, branch or tag+ :code+ # lang: ruby+ git 'https://github.com/rails/rails.git', :ref => '4aded' do+ git 'https://github.com/rails/rails.git', :branch => '5-0-stable' do+ git 'https://github.com/rails/rails.git', :tag => 'v5.0.0' do+ .bullet+ .description
Specifying a ref, branch, or tag for a
git repository specified inline works
exactly the same way
--~~~ ruby-gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git', :ref => '0eec4'-~~~-+ :code+ # lang: ruby+ gem 'nokogiri', :git => 'https://github.com/rack/rack.git', :ref => '0bd839d'+ gem 'nokogiri', :git => 'https://github.com/rack/rack.git', :tag => '2.0.1'+ gem 'nokogiri', :git => 'https://github.com/rack/rack.git', :branch => 'rack-1.5'+ .bullet+ .description
Bundler can use HTTP(S), SSH, or git
--~~~ ruby-gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git'-gem 'nokogiri', :git => '[email protected]:tenderlove/nokogiri.git'-gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git'-~~~-+ :code+ # lang: ruby+ gem 'rack', :git => 'https://github.com/rack/rack.git'+ gem 'rack', :git => '[email protected]:rack/rack.git'+ gem 'rack', :git => 'git://github.com/rack/rack.git'+ .bullet+ .description
Specify that the submodules from a git repository
also should be expanded by bundler
--~~~ ruby+ :code+ # lang: ruby
gem 'rugged', :git => 'git://github.com/libgit2/rugged.git', :submodules => true
-~~~-+ .bullet+ .description
If you are getting your gems from a public GitHub repository,
you can use the shorthand
--~~~ ruby-gem 'nokogiri', :github => 'tenderlove/nokogiri'-~~~-+ :code+ # lang: ruby+ gem 'rack', :github => 'rack/rack'+ .description
If the repository name is the same as the GitHub account hosting it,
you can omit it
--~~~ ruby+ :code+ # lang: ruby
gem 'rails', :github => 'rails'
-~~~-+ .description
<b>NB:</b> This shorthand can only be used for public repos in Bundler version 1.x. Use HTTPS for read and write:
--~~~ ruby+ :code+ # lang: ruby
gem 'rails', :git => 'https://github.com/rails/rails'
-~~~-+ .description
All of the usual <code>:git</code> options apply, like <code>:branch</code> and <code>:ref</code>.
--~~~ ruby+ :code+ # lang: ruby
gem 'rails', :github => 'rails', :ref => 'a9752dcfd15bcddfe7b6f7126f3a6e0ba5927c56'
-~~~-+ .description
There are analogous shortcuts for Bitbucket (<code>:bitbucket</code>) and GitHub Gists (<code>:gist</code>).
--~~~ ruby+ :code+ # lang: ruby
gem 'capistrano-sidekiq', :github => 'seuros/capistrano-sidekiq'
gem 'keystone', :bitbucket => 'musicone/keystone'
-~~~--## Custom git sources-+ %h2 Custom git sources+ .contents+ .bullet+ .description
The <code>:github</code> shortcut used above is one of Bundler's built in git sources. Bundler comes
with shortcuts for <code>:github</code>, <code>:gist</code>, and <code>:bitbucket</code>, but you can
also add your own.
+ .description
If you're using Github Enterprise, Stash, or just have a custom git setup, create your own shortcuts
by calling <code>git_source</code> before you use your custom option. Here's an example for Stash:
-~~~ ruby+ :code+ # lang: ruby
git_source(:stash){ |repo_name| "https://stash.corp.acme.pl/\#{repo_name}.git" }
gem 'rails', :stash => 'forks/rails'
-~~~--## Security-+ %h2 Security+ .contents+ .bullet+ .description
<code>http://</code> and <code>git://</code> URLs are insecure. A
man-in-the-middle attacker could tamper with the code as you check it out,
and potentially supply you with malicious code instead of the code you meant to
@@ -130,24 +132,28 @@
URL in Bundler 1.x versions, we recommend using HTTPS URLs or overriding
the <code>:github</code> shortcut with your own HTTPS git source.
-## Local Git Repos-+ %h2#local Local Git Repos+ .contents+ .bullet+ .description
Bundler also allows you to work against a git repository locally
instead of using the remote version. This can be achieved by setting
up a local override:
-- bundle config local.GEM_NAME /path/to/local/git/repository-+ :code+ $ bundle config local.GEM_NAME /path/to/local/git/repository+ .bullet+ .description
For example, in order to use a local Rack repository, a developer could call:
-- bundle config local.rack ~/Work/git/rack-+ :code+ $ bundle config local.rack ~/Work/git/rack+ .description
and setup the git repo pointing to a branch:
--~~~ ruby+ :code+ # lang: ruby
gem 'rack', :github => 'rack/rack', :branch => 'master'
-~~~-+ .bullet+ .description+ %p
Now instead of checking out the remote git repository, the local
override will be used. Similar to a path source, every time the local
git repository change, changes will be automatically picked up by
@@ -157,6 +163,7 @@
the remote, you need to ensure the local override was pushed, otherwise
you may point to a commit that only exists in your local machine.
+ %p
Bundler does many checks to ensure a developer won't work with
invalid references. Particularly, we force a developer to specify
a branch in the <code>Gemfile</code> in order to use this feature. If the branch
@@ -165,10 +172,13 @@
a developer is always working against the correct branches, and prevents
accidental locking to a different branch.
+ %p
Finally, Bundler also ensures that the current revision in the
<code>Gemfile.lock</code> exists in the local git repository. By doing this, Bundler
forces you to fetch the latest changes in the remotes.
-If you do not want bundler to make these branch checks, you can override it by setting this option:-- bundle config disable_local_branch_check true+ .bullet+ .description+ %p If you do not want bundler to make these branch checks, you can override it by setting this option:+ :code+ $ bundle config disable_local_branch_check true
groups
--- source/v1.12/groups.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/groups.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,15 +1,17 @@
---
-title: Using Groups-description: Grouping your dependencies allows you to perform operations on the entire group+title: "Managing groups of gems"
---
+.container.guide+ %h2 Using Groups-## Using Groups-+ .contents+ .bullet+ .description
Grouping your dependencies allows you
to perform operations on the entire
group.
--~~~ ruby+ :code+ # lang: ruby
# These gems are in the :default group
gem 'nokogiri'
gem 'sinatra'
@@ -27,45 +29,46 @@
end
gem 'cucumber', :group => [:cucumber, :test]
-~~~-+ .bullet+ .description
Install all gems, except those in the
listed groups. Gems in at least one
non-excluded group will still be installed.
-+ :code
$ bundle install --without test development
-+ .bullet+ .description
Require the gems in particular groups,
noting that gems outside of a named group
are in the :default group
--~~~ ruby+ :code+ # lang: ruby
Bundler.require(:default, :development)
-~~~-+ .bullet+ .description
Require the default gems, plus the gems
in a group named the same as the current
Rails environment
--~~~ ruby+ :code+ # lang: ruby
Bundler.require(:default, Rails.env)
-~~~-+ .bullet+ .description
Restrict the groups of gems that you
want to add to the load path. Only gems
in these groups will be require'able
--~~~ ruby+ :code+ # lang: ruby
require 'rubygems'
require 'bundler'
Bundler.setup(:default, :ci)
require 'nokogiri'
-~~~--<a class="btn btn-primary" href="/bundler_setup.html">Learn More: Bundler.setup</a>--## Grouping Your Dependencies+ = link_to 'Learn More: Bundler.setup', './bundler_setup.html', class: 'btn btn-primary'+ %h2#grouping-your-dependencies+ Grouping Your Dependencies+ .bullet+ .description
You'll sometimes have groups of gems that only make sense in particular environments.
For instance, you might develop your app (at an early stage) using SQLite, but deploy it
using <code>mysql2</code> or <code>pg</code>. In this example, you might not have MySQL
@@ -73,7 +76,8 @@
To do this, you can group your dependencies:
-~~~ ruby+ :code+ # lang: ruby
source 'https://rubygems.org'
gem 'rails', '3.2.2'
@@ -87,37 +91,44 @@
group :production do
gem 'pg'
end
-~~~-+ .bullet+ .description
Now, in development, you can instruct bundler to skip the <code>production</code> group:
+ :code
$ bundle install --without production
-+ .bullet+ .description
Bundler will remember that you installed the gems using <code>--without
production</code>. For curious readers, bundler stores the flag in
<code>APP_ROOT/.bundle/config</code>. You can see all of the settings that bundler saved
there by running <code>bundle config</code>, which will also print out global settings
(stored in <code>~/.bundle/config</code>), and settings set via environment variables.
For more information on configuring bundler, please see:
-[bundle config](/v1.12/bundle_config.html)+ #{link_to_documentation "bundle_config"}+ .bullet+ %p.description
If you run <code>bundle install</code> later, without any flags, bundler will remember
that you last called <code>bundle install --without production</code>, and use that flag
again. When you <code>require 'bundler/setup'</code>, bundler will ignore gems in these
groups.
+ %p.description
You can also specify which groups to automatically require through the parameters to
<code>Bundler.require</code>. The <code>:default</code> group includes all gems not
listed under any group. If you call <code>Bundler.require(:default, :development)</code>,
bundler will <code>require</code> all the gems in the <code>:default</code> group, as
well as the gems in the <code>:development</code> group.
+ %p.description
By default, a Rails generated app calls <code>Bundler.require(:default,
Rails.env)</code> in your <code>application.rb</code>, which links the groups in your
<code>Gemfile</code> to the Rails environment. If you use other groups (not linked to a
Rails environment), you can add them to the call to <code>Bundler.require</code>, if you
want them to be automatically required.
+ %p.description
Remember that you can always leave groups of gems out of <code>Bundler.require</code>,
and then require them manually using Ruby's <code>require</code> at the appropriate
place in your app. You might do this because requiring a certain gem takes some time,
rails {rails3 and rails}
Guides for v1.12 had rails3 (and rails23) instead of rails.
--- source/v1.12/rails3.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/rails.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,66 +1,76 @@
---
-title: Using Bundler with Rails 2.3+title: Using Bundler with Rails
---
--Rails 3 comes with baked in support with bundler.--## Using Bundler with Rails 3-+.container.guide+ #intro+ Rails comes with baked in support with bundler.++ %h2 Using Bundler with Rails++ .contents+ .bullet+ .description
Install Rails as you normally would. Use sudo
if you would normally use sudo to install gems.
-+ .how+ :code
$ gem install rails
-+ .notes
We recommend using rvm for dependable Ruby
installations, especially if you are switching
between different versions of Ruby
+ .bullet+ .description
Generate a Rails app as usual
-+ :code
$ rails new myapp
$ cd myapp
-+ .bullet+ .description
Run the server. Bundler is transparently managing
your dependencies!
-+ :code
$ rails server
-+ .bullet+ .description
Add new dependencies to your Gemfile as you
need them.
--~~~ ruby+ :code+ # lang: ruby
gem 'nokogiri'
gem 'geokit'
-~~~-+ .bullet+ .description
If you want a dependency to be loaded only in
a certain Rails environment, place it in a group
named after that Rails environment
--~~~ ruby+ :code+ # lang: ruby
group :test do
gem 'rspec'
gem 'faker'
end
-~~~-+ .bullet#shared_with_23+ .description
You can place a dependency in multiple groups
at once as well
--~~~ ruby+ :code+ # lang: ruby
group :development, :test do
gem 'wirble'
gem 'ruby-debug'
end
-~~~--<a class="btn btn-primary" href="/groups.html">Learn More: Groups</a>+ = link_to 'Learn More: Groups', './groups.html', class: 'btn btn-primary'+ .bullet+ .description
After adding a dependency, if it is not yet
installed, install it
-+ .how+ :code
$ bundle install
-+ .notes
This will update all dependencies in your
Gemfile to the latest versions that do not
conflict with other dependencies
sinatra
--- source/v1.12/sinatra.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/sinatra.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,18 +1,22 @@
---
title: Using Bundler with Sinatra
---
+.container.guide+ %h2 Using Bundler with Sinatra-## Using Bundler with Sinatra-+ .contents+ .bullet+ .description
To use bundler with a Sinatra application, you only need to do two things. First, create a Gemfile.
--~~~ ruby+ :code+ # lang: ruby
gem 'sinatra'
-~~~+ .bullet+ .description
Then, set up your config.ru file to load the bundle before it loads your Sinatra app.
--~~~ ruby+ :code+ # lang: ruby
require 'rubygems'
require 'bundler'
@@ -20,8 +24,9 @@
require './my_sinatra_app'
run MySinatraApp
-~~~+ .bullet+ .description
Start your development server with rackup, and Sinatra will be loaded via Bundler.
-+ :code
$ bundle exec rackup
updating_gems
--- source/v1.12/updating_gems.html.md 2022-07-08 07:52:54.000000000 +0000+++ source/v1.15/guides/updating_gems.html.haml 2022-07-08 07:52:54.000000000 +0000@@ -1,11 +1,15 @@
---
title: Updating Gems
---
+.container.guide+ %h2 Updating Gems+ .contents+ .bullet+ .description+ %h3#updating-a-dependency+ Updating a Dependency-## Updating Gems--### Updating a Dependency-+ %p.description
Of course, at some point, you might want to update the version of a particular
dependency your application relies on. For instance, you might want to update
<code>rails</code> to <code>3.0.0</code> final. Importantly, just because you're
@@ -13,6 +17,7 @@
and use the latest version of everything. In our example, you only have three
dependencies, but even in this case, updating everything can cause complications.
+ %p.description
To illustrate, the <code>rails 3.0.0.rc</code> gem depends on <code>actionpack
3.0.0.rc</code> gem, which depends on <code>rack ~> 1.2.1</code> (which means <code>>=
1.2.1</code> and <code>< 1.3.0</code>). The <code>rack-cache</code> gem depends on
@@ -20,7 +25,7 @@
depends on <code>rack ~> 1.2.1</code>, and that since the release of <code>rails
3.0.0</code>, the Rack team released <code>rack 1.2.2</code>.
-+ %p.description
If we naïvely update all of our gems in order to update Rails, we'll get <code>rack
1.2.2</code>, which satisfies the requirements of both <code>rails 3.0.0</code> and
<code>rack-cache</code>. However, we didn't specifically ask to update
@@ -29,6 +34,7 @@
1.2.2</code> probably won't break anything, similar scenarios can happen that involve
much larger jumps. (see [1] below for a larger discussion)
+ %p.description
In order to avoid this problem, when you update a gem, bundler will not update a
dependency of that gem if another gem still depends on it. In this example, since
<code>rack-cache</code> still depends on <code>rack</code>, bundler will not update the
@@ -38,12 +44,14 @@
leaves it alone, and <code>rack-cache</code> continues to work even in the face of an
incompatibility with <code>rack 1.2.2</code>.
+ %p.description
Since you originally declared a dependency on <code>rails 3.0.0.rc</code>, if you want
to update to <code>rails 3.0.0</code>, simply update your <code>Gemfile</code> to
<code>gem 'rails', '3.0.0'</code> and run:
+ :code
$ bundle install
-+ %p.description
As described above, the <code>bundle install</code> command always does a conservative
update, refusing to update gems (or their dependencies) that you have not explicitly
changed in the <code>Gemfile</code>. This means that if you do not modify
@@ -53,6 +61,7 @@
conflict between your snapshotted dependencies (<code>Gemfile.lock</code>) and your
updated <code>Gemfile</code>.
+ %p.description
If you update your <code>Gemfile</code>, and your system already has all of the needed
dependencies, bundler will transparently update the <code>Gemfile.lock</code> when you
boot your application. For instance, if you add <code>mysql</code> to your
@@ -60,6 +69,7 @@
application without running <code>bundle install</code>, and bundler will persist the
"last known good" configuration to the <code>Gemfile.lock</code> snapshot.
+ %p.description
This can come in handy when adding or updating gems with minimal dependencies (database
drivers, <code>wirble</code>, <code>ruby-debug</code>). It will probably fail if you
update gems with significant dependencies (<code>rails</code>), or that a lot of gems
@@ -67,8 +77,12 @@
to boot, and bundler will print out an error instructing you to run <code>bundle
install</code>.
-### Updating a Gem Without Modifying the Gemfile+ .bullet+ .description+ %h3#updating-a-gem-without-modifying-the-gemfile+ Updating a Gem Without Modifying the Gemfile+ %p
Sometimes, you want to update a dependency without modifying the Gemfile. For example,
you might want to update to the latest version of <code>rack-cache</code>. Because you
did not declare a specific version of <code>rack-cache</code> in the
@@ -76,22 +90,26 @@
<code>rack-cache</code>. To do this, you want to use the <code>bundle update</code>
command:
+ :code
$ bundle update rack-cache
-+ %p
This command will update <code>rack-cache</code> and its dependencies to the latest
version allowed by the <code>Gemfile</code> (in this case, the latest version
available). It will not modify any other dependencies.
+ %p
It will, however, update dependencies of other gems if necessary. For instance, if the
latest version of <code>rack-cache</code> specifies a dependency on <code>rack >=
1.2.2</code>, bundler will update <code>rack</code> to <code>1.2.2</code> even though
you have not asked bundler to update <code>rack</code>. If bundler needs to update a
gem that another gem depends on, it will let you know after the update has completed.
+ %p
If you want to update every gem in the Gemfile to the latest possible versions, run:
+ :code
$ bundle update
-+ %p
This will resolve dependencies from scratch, ignoring the <code>Gemfile.lock</code>. If
you do this, keep <code>git reset --hard</code> and your test suite in your back pocket.
Resolving all dependencies from scratch can have surprising results, especially if a
The text was updated successfully, but these errors were encountered:
How different between 1.12 and 1.15
echo bundler_setup bundler_sharing deploying faq git_bisect git groups rails sinatra updating_gems | xargs -I {} diff -uw source/v1.12/{}.html.* source/v1.15/guides/{}.htmlbundler_setup
bundler_sharing
deploying
faq
git_bisect
git
groups
rails {rails3 and rails}
Guides for v1.12 had
rails3(andrails23) instead ofrails.sinatra
updating_gems
The text was updated successfully, but these errors were encountered: