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
We introduced breaking changes in RubyGems/Bundler 4 in order to improve usability, security, and maintainability of the tool. This document describes the changes that you will find when upgrading to RubyGems 4 and Bundler 4, and how to prepare for them while still using Bundler 2.7.
The `--default` option was confusing for RubyGems users and caused broken installs.
21
19
22
20
This was an unfinished feature originally intended to install gems directly into the Ruby standard library location, but it only generated executables without properly copying library files. This partial implementation led to a complicated environment with no real benefit for users.
23
21
24
-
###API behavior changes
22
+
##RubyGems 4: API behavior changes
25
23
26
-
####No replacements for removed deprecated methods
24
+
### No replacements for removed deprecated methods
27
25
28
26
The following deprecated methods have been removed with no replacement:
29
27
@@ -34,17 +32,15 @@ The following deprecated methods have been removed with no replacement:
34
32
*`Gem::Specification#default_executable`
35
33
*`Gem::Installer#unpack`
36
34
37
-
####Removed deprecated Gem::Platform.match
35
+
### Removed deprecated Gem::Platform.match
38
36
39
37
Please use `Gem::Platform.match_spec?` or `match_gem?` instead.
Please use `Gem.default_specifications_dir` instead.
44
42
45
-
## Bundler 4
46
-
47
-
### Bundler 4 simulation mode
43
+
## Bundler 4 simulation mode
48
44
49
45
In order to prepare for Bundler 4, you can easily configure Bundler 2.7 to behave exactly like Bundler 4 will behave. To do so, you have three options:
50
46
@@ -56,9 +52,9 @@ From now on in this document we will assume that all three of these configuratio
56
52
57
53
The following is a summary of the changes that we introduced in Bundler 4, and why we made those changes. Some of them should be well known already by existing users, because we have been printing deprecation messages for years, but some of them are defaults that were switched in Bundler 4.
58
54
59
-
###CLI behavior changes
55
+
##Bundler 4: CLI behavior changes
60
56
61
-
####Running just `bundle` to mean `bundle install` is not recommended anymore
57
+
### Running just `bundle` to mean `bundle install` is not recommended anymore
62
58
63
59
We changed this default to make Bundler more friendly for new users. We do understand that long time users already know how Bundler works and found it useful that just `bundle` defaulted to `bundle install`.
64
60
@@ -78,7 +74,7 @@ bundle config set default_cli_command cli_help --global
78
74
79
75
Please use `bundle install` explicitly in your scripts and documentation, so that everyone is clear about what is happening.
80
76
81
-
####Flags passed to `bundle install` that relied on being remembered across invocations have been removed
77
+
### Flags passed to `bundle install` that relied on being remembered across invocations have been removed
82
78
83
79
In particular, the `--clean`, `--deployment`, `--frozen`, `--no-prune`, `--path`, `--shebang`, `--system`, `--without`, and `--with` options to `bundle install`.
84
80
@@ -90,15 +86,15 @@ The problem with this behavior was that very common workflows were relying on it
90
86
91
87
This magic has been removed from Bundler 4, and you now explicitly need to configure it, either through environment variables, application configuration, or machine configuration. For example, with `bundle config set --local without development test`.
92
88
93
-
####`bundle viz` has been removed and extracted to a plugin.
89
+
### `bundle viz` has been removed and extracted to a plugin.
94
90
95
91
This was the only bundler command requiring external dependencies, both an OS dependency (the `graphviz` package) and a gem dependency (the `ruby-graphviz` gem). Removing these dependencies made development easier and it was also seen by the bundler team as an opportunity to develop a bundler plugin that is officially maintained by the RubyGems team, and that users can take as a reference to develop their own plugins.
96
92
97
93
The new plugin is called `bundler-graph` and it is available at https://github.com/rubygems/bundler-grap now.
98
94
99
95
The plugin contains the same code as the old core command, the only difference being that the command is now implemented as `bundle graph` which is much easier to understand.
100
96
101
-
####The `bundle install` command no longer accepts a `--binstubs` flag.
97
+
### The `bundle install` command no longer accepts a `--binstubs` flag.
102
98
103
99
The `--binstubs` option has been removed from `bundle install` and replaced with the `bundle binstubs` command.
104
100
@@ -110,25 +106,26 @@ If you still want to create binstubs for all gems, you can run:
110
106
bundle binstubs --all
111
107
```
112
108
113
-
####The `bundle inject` command has been replaced with `bundle add`
109
+
### The `bundle inject` command has been replaced with `bundle add`
114
110
115
111
We believe the new command fits the user's mental model better and it supports a wider set of use cases.
116
112
117
113
The interface supported by `bundle inject` works exactly the same in `bundle add`, so it should be easy to migrate to the new command.
118
114
119
-
###Gemfile and lockfile behavior changes
115
+
##Bundler 4: Gemfile and lockfile behavior changes
120
116
121
-
####Bundler includes checksums in new lockfiles by default
117
+
### Bundler includes checksums in new lockfiles by default
122
118
123
119
We shipped this security feature and turned it on by default, so that everyone benefits from the extra security assurances. So whenever you create a new lockfile, Bundler now includes a CHECKSUMS section.
124
120
125
121
Bundler will not automatically add a CHECKSUMS section to existing lockfiles, though, unless explicitly requested through `bundle lock --add-checksums`.
126
122
127
-
####Strict source pinning in Gemfile is enforced by default
123
+
### Strict source pinning in Gemfile is enforced by default
128
124
129
125
In Bundler 4, the source for every dependency is now unambiguously defined, and Bundler refuses to run otherwise.
130
126
131
-
##### Multiple global Gemfile sources are no longer supported.
127
+
* Multiple global Gemfile sources are no longer supported.
128
+
132
129
Instead of something like this:
133
130
134
131
```ruby
@@ -151,7 +148,7 @@ source "https://another_source" do
151
148
end
152
149
```
153
150
154
-
#####Global `path` and `git` sources are no longer supported.
151
+
* Global `path` and `git` sources are no longer supported.
155
152
156
153
Instead of something like this:
157
154
@@ -186,54 +183,51 @@ git "https://my_git_repo_with_gems" do
186
183
end
187
184
```
188
185
189
-
###Cache behavior changes
186
+
##Bundler 4: Cache behavior changes
190
187
191
-
####Git and Path gems are included in `vendor/cache` by default
188
+
### Git and Path gems are included in `vendor/cache` by default
192
189
193
190
If you have a `vendor/cache` directory (to support offline scenarios, for example), Bundler now includes gems from `path` and `git` sources in there.
194
191
195
192
We're unsure why these gems were treated specially so we'll start caching them normally.
196
193
197
-
####Bundler uses cached local data if available when network issues are found during resolution
194
+
### Bundler uses cached local data if available when network issues are found during resolution
198
195
199
196
Just trying to provide a more resilient behavior here.
200
197
201
-
###API behavior changes
198
+
##Bundler 4: API behavior changes
202
199
203
-
####`Bundler.clean_env`, `Bundler.with_clean_env`, `Bundler.clean_system`, and `Bundler.clean_exec` have been removed
200
+
### `Bundler.clean_env`, `Bundler.with_clean_env`, `Bundler.clean_system`, and `Bundler.clean_exec` have been removed
204
201
205
202
All of these helpers ultimately used `Bundler.clean_env` under the hood, which made sure all bundler-related environment variables were removed inside the block it yields.
206
203
207
204
After quite a lot of user reports, we noticed that users don't usually want this but instead want the bundler environment as it was before the current process was started. Thus, `Bundler.with_original_env`, `Bundler.original_system`, and `Bundler.original_exec` were born. They all use the new `Bundler.original_env` under the hood.
208
205
209
206
There are however some specific cases where the good old `Bundler.clean_env` behavior can be useful. For example, when testing Rails generators, you really want an environment where `bundler` is out of the picture. This is why we decided to keep the old behavior under a new more clear name, because we figured the word "clean" was too ambiguous. So we introduced `Bundler.unbundled_env`, `Bundler.with_unbundled_env`, `Bundler.unbundled_system`, and `Bundler.unbundled_exec`.
210
207
211
-
####`Bundler.environment` has been deprecated in favor of `Bundler.load`.
208
+
### `Bundler.environment` has been deprecated in favor of `Bundler.load`.
212
209
213
210
We're not sure how people might be using this directly but we removed the `Bundler::Environment` class which was instantiated by `Bundler.environment` since we realized the `Bundler::Runtime` class was the same thing. `Bundler.environment` now delegates to `Bundler.load`, which holds the reference to the `Bundler::Runtime`.
214
211
215
-
#### Removed public methods of `Bundler::SpecSet`
216
-
217
-
The following public methods of `Bundler::SpecSet` have been removed with no replacement:
212
+
### Removed public methods of `Bundler::SpecSet`
218
213
219
-
*`SpecSet#-`
220
-
*`SpecSet#<<`
214
+
`SpecSet#-` and `SpecSet#<<` have been removed with no replacement:
`SpecSet#for` received a `check` parameter, but that's no longer used and deprecated. Please remove this parameter.
225
219
226
-
####`CurrentRuby#maglev?` was removed with no replacement.
220
+
### `CurrentRuby#maglev?` was removed with no replacement.
227
221
228
222
Please use the built-in Ruby `RUBY_ENGINE` constant to check the Ruby implementation you are running on.
229
223
230
-
####`Bundler.rubygems.all_specs` has been removed
224
+
### `Bundler.rubygems.all_specs` has been removed
231
225
232
226
Please use `Bundler.rubygems.installed_specs` instead.
233
227
234
-
###Other notable changes
228
+
##Bundler 4: Other notable changes
235
229
236
-
####Deployment helpers for `vlad` and `capistrano` have been removed.
230
+
### Deployment helpers for `vlad` and `capistrano` have been removed.
237
231
238
232
These were natural deprecations since the `vlad` tool has had no activity for years whereas `capistrano` 3 has built-in Bundler integration in the form of the `capistrano-bundler` gem, and everyone using Capistrano 3 should already be using that instead. If for some reason, you are still using Capistrano 2, feel free to copy the Capistrano tasks out of the Bundler 2 file `lib/bundler/deployment.rb` and put them into your app.
0 commit comments