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
|
## Bundler 0.9 to 1.0 and above
Upgrading from Bundler 0.9 to 1.0 is relatively painless. The
Gemfile API is the same, so your old Gemfiles should continue
to work.
The "env" file that 0.9 created at `.bundle/environment.rb` has been
removed. As a side effect of this, Passenger will only find your
bundled gems if you install with `bundle install --deployment`.
Alternatively, you can tell Passenger where you gems are installed,
[something like this](http://andre.arko.net/2010/08/16/using-passengerpane-with-gem_home-set/).
The `bundle lock` command is no longer needed, as the
Gemfile.lock file is now automatically generated by `bundle install`.
If you have not yet done so, add your Gemfile.lock to source control
and check it in.
Running `bundle install` no longer updates the versions of your gems.
If you need to update just one gem, run `bundle update GEMNAME`. To
update all gems to the newest versions possible, run `bundle update`.
Bundler now supports multiple platforms, using a block syntax to
declare platform-specific gems:
platform :jruby do
gem "jruby-maven-plugins"
end
Deploying using Bundler is even easier than it was before, as Bundler
now includes a Capistrano recipe. Simply add this line to the top of
your deploy.rb file to run Bundler automatically as part of deploying:
require 'bundler/capistrano'
For more details on deploying using bundler, see the documentation
for the bundler cap task, and the [documentation on deploying](http://bundler.io/deploying.html).
## Bundler 0.8 to 0.9 and above
Upgrading to Bundler 0.9 from Bundler 0.8 requires upgrading several
API calls in your Gemfile, and some workarounds if you are using Rails 2.3.
### Gemfile Removals
Bundler 0.9 removes the following Bundler 0.8 Gemfile APIs:
1. `disable_system_gems`: This is now the default (and only) option
for bundler. Bundler uses the system gems you have specified
in the Gemfile, and only the system gems you have specified
(and their dependencies)
2. `disable_rubygems`: This is no longer supported. We are looking
into ways to get the fastest performance out of each supported
scenario, and we will make speed the default where possible.
3. `clear_sources`: Bundler now defaults to an empty source
list. If you want to include Rubygems, you can add the source
via source "http://gemcutter.org". If you use bundle init, this
source will be automatically added for you in the generated
Gemfile
4. `bundle_path`: You can specify this setting when installing
via `bundle install /path/to/bundle`. Bundler will remember
where you installed the dependencies to on a particular
machine for future installs, loads, setups, etc.
5. `bin_path`: Bundler no longer generates executables in the root
of your app. You should use `bundle exec` to execute executables
in the current context.
### Gemfile Changes
Bundler 0.9 changes the following Bundler 0.8 Gemfile APIs:
1. Bundler 0.8 supported :only and :except as APIs for describing
groups of gems. Bundler 0.9 supports a single `group` method,
which you can use to group gems together. See the above "Group"
section for more information.
This means that `gem "foo", :only => :production` becomes
`gem "foo", :group => :production`, and
`only :production { gem "foo" }` becomes
`group :production { gem "foo" }`
The short version is: group your gems together logically, and
use the available commands to make use of the groups you've
created.
2. `:require_as` becomes `:require`
3. `:vendored_at` is fully removed; you should use `:path`
### API Changes
1. `Bundler.require_env(:environment)` becomes
`Bundler.require(:multiple, :groups)`. You must
now specify the default group (the default group is the
group made up of the gems not assigned to any group)
explicitly. So `Bundler.require_env(:test)` becomes
`Bundler.require(:default, :test)`
2. `require 'vendor/gems/environment'`: In unlocked
mode, where using system gems, this becomes
`Bundler.setup(:multiple, :groups)`. If you don't
specify any groups, this puts all groups on the load
path. In locked mode, it becomes `require '.bundle/environment'`
|
