| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Since it did not cause the changed config to be written to disk
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Speed up no-op installs
### What was the end-user problem that led to this PR?
The problem was that a "no-op `bundle install`", defined as a user running `bundle install` when `bundle check` would have succeeded was taking roughly 4 times as long as `bundle check`.
Closes #5842.
### What was your diagnosis of the problem?
My diagnosis was that there were a few different bottlenecks:
- loading plugins
- using `Bundler::Worker` when the work done in that workers block would finish nearly instantly
- some unoptimized code in the parallel installer
### What is your fix for the problem, implemented in this PR?
My fix avoids the bottlenecks by checking if the `install` is guaranteed to be a no-op and short-circuiting all but the core `install` method, which in turn will now avoid the `Bundler::Worker` overhead and quickly cache gems when needed.
### Why did you choose this fix out of the possible options?
I chose this fix because it succeeded in speeding up no-op installs by a _huge_ margin.
This _should_ make `install` nearly as fast as a `bundle check`, but at the moment it's still around ~200ms slower. Not an insignificant gap, but a far cry from what it was before the patch. Additionally, since the `install` code path does things such as ensuring everything is cached.
### Time
Run against https://gist.github.com/indirect/6f60f0db1e2f86804ca3ac7c01f2afc4
```
$ time dbundle check
The Gemfile's dependencies are satisfied
BUNDLE_DISABLE_POSTIT=1 ruby ~/Development/OpenSource/bundler/exe/bundle 0.32s user 0.06s system 94% cpu 0.403 total
```
```
$ time bundle check
The Gemfile's dependencies are satisfied
BUNDLE_DISABLE_POSTIT=1 ruby ~/Development/OpenSource/bundler/exe/bundle 0.34s user 0.05s system 96% cpu 0.404 total
```
```
$ time dbundle install --quiet
BUNDLE_DISABLE_POSTIT=1 ruby ~/Development/OpenSource/bundler/exe/bundle 0.48s user 0.07s system 95% cpu 0.582 total
```
```
$ time bundle install --quiet
BUNDLE_DISABLE_POSTIT=1 ruby ~/Development/OpenSource/bundler/exe/bundle 1.68s user 0.30s system 92% cpu 2.146 total
```
|
| |/
|
|
| |
This should make them nearly as fast a bundle check
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Return an empty array if no extensions are found
### What was the end-user problem that led to this PR?
Attempting to compare endpoint specifications that didn't have any extensions was causing a `NoMethodError: undefined method `empty?' for nil:NilClass` error.
### What was your diagnosis of the problem?
The `extensions` method on `EndpointSpecification` was incorrectly returning `nil` when there were no extensions.
### What is your fix for the problem, implemented in this PR?
~~Return an empty array in that case, instead~~ Fall back to the base class implementation in that case, instead.
### Why did you choose this fix out of the possible options?
~~Alternative would be to call `super`. I presumed there was a reason that wasn't being done already, but it would also work.~~ Alternative would be to explicitly return an empty array, but all other methods call `super`, which feels more robust.
|
| | | |
|
| | | |
|
| |\ \
| |/
| |
| |
| |
| |
| |
| | |
Fix spec on 2.0 broken with the v1.15.2 merge
### What was the end-user problem that led to this PR?
The problem was I merged in a change necessary to keep the 1.15.x specs passing accidentally, even though it broke the 2.0 spec. Oops.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Version 1.15.2
# Conflicts:
# Rakefile
# doc/development/SETUP.md
# lib/bundler/cli.rb
# lib/bundler/installer.rb
# lib/bundler/setup.rb
# spec/commands/install_spec.rb
# spec/quality_spec.rb
# spec/runtime/inline_spec.rb
# spec/support/artifice/compact_index_partial_update.rb
# spec/support/rubygems_ext.rb
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Limit specs to rack-test < 0.7.0 for Ruby 1.8.7 compatibility
### What was the end-user problem that led to this PR?
The problem was the specs were broken by the release of `rack-test 0.7.0`.
### What was your diagnosis of the problem?
My diagnosis was `rack-test` has intentionally dropped 1.8.7 support, though we didn't catch that immediately because they didn't put a `required_ruby_version` in their gemspec.
### What is your fix for the problem, implemented in this PR?
My fix pins us to older versions of the gem.
(cherry picked from commit b9851e2fd1d9a2dc7675f713a12c0d4209285d7f)
# Conflicts:
# spec/support/rubygems_ext.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid Range Not Satisfiable errors during normal request flow
### What was the end-user problem that led to this PR?
Previously, Bundler was requesting partial response ranges for the Rubygems compact index that could be empty. Since Rubygems was [ignoring the `ETag` header](https://github.com/rubygems/rubygems.org/pull/1652) for these requests, empty ranges would occur whenever the versions index (for instance) hadn't been modified since the version Bundler currently had cached. When this happened, Rubygems would respond with a 416 (Range Not Satisfiable). Bundler would treat this as a `Bundler::HTTPError`, and fall back to using `Fetcher::Dependency` for dependency info. Sadly, that meant metadata about what Ruby version each dependency required was no-longer checked, and updates for gems which should be limited by the system Ruby version were failing.
Closes #5373.
### What was your diagnosis of the problem?
See above
### What is your fix for the problem, implemented in this PR?
This PR updates the range Bundler requests from Rubygems to ensure it's always satisfiable. It does that but requesting all bytes from (and including) the final byte in the Bundler cache, rather than all bytes after (and not including) it.
### Why did you choose this fix out of the possible options?
An alternative fix would be to catch the 416 responses and retry the index lookup in those cases, asking for a full response. That would mean an extra request in all of those cases, though - this method keeps the number of calls to Rubygems down.
(cherry picked from commit 288b3c90d9db4e3f367748e9ae29c276db95e941)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[Inline] Work when BUNDLE_BIN is set
### What was the end-user problem that led to this PR?
The problem was that `bundler/inline` would fail when `$BUNDLE_BIN` was set.
Closes #5847.
### What was your diagnosis of the problem?
My diagnosis was we needed to skip installing binstubs when doing an inline install.
### What is your fix for the problem, implemented in this PR?
My fix sets a temporary setting for `:inline` and skips installing binstubs when that's true.
### Why did you choose this fix out of the possible options?
I chose this fix because it was minimally intrusive.
(cherry picked from commit 1075e4454c771782c7a00dda676d17bcca66d401)
# Conflicts:
# lib/bundler/installer.rb
# spec/quality_spec.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=segiddins
Compare sources using source's root
### What was the end-user problem that led to this PR?
Given a setup where:
1. A project's Gemfile makes use of another project's Gemfile and the `eval_gemfile` method to share the dependencies. Something like:
```ruby
# project_plugin's Gemfile
eval_gemfile(File.expand_path("../../main_project/Gemfile", __FILE__))
```
2. The main project includes a path gem in it that is nested in the main project:
```ruby
# main_project's Gemfile
gem "foo_gem", :path => "vendor/foo_gem"
```
3. A `bundle install` is followed by a `bundle install --deployment`, the second of which triggers a comparison of the `lockfile.sources` and the `Bundler.definition`
A error will occur when comparing the specs, saying the the "foo_gem" source has been deleted:
```console
$ bundle install
...
$ bundle install --deployment
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
the gemspecs for path gems changed
You have deleted from the Gemfile:
* source: source at `../main_project/vendor/foo_gem`
```
### What was your diagnosis of the problem?
(extracted from the commit message)
When doing the following:
expand(other.original_path)
inside a `Bundler::Source::Path` instance, the `@root_path` from the instance that is having `eq?` called on it, the the `other` instance's `root_path`. This, in obscure cases, can cause a bug when you are doing an nested eval_gemfile or other calls when comparing the lockfile's locked path sources to the `Bundler.definition`'s path sources.
### What is your fix for the problem, implemented in this PR?
Use a new public method, `Bundler::Source::Path#expanded_original_path`, in the `eq?` method instead of using's the instance's `#expand` method.
### Why did you choose this fix out of the possible options?
(extracted from the commit message)
Creating the `expanded_original_path` method allows a public interface to be made available (and doesn't mess with any exiting functionality) that allows comparing the source path of one `Source::Path`'s `expand_path` to another, where each uses their own `root_path` to resolve their full path, instead of sharing the base one and causing edge case bugs
(cherry picked from commit fb3384649d866f08cb59683be8a711290aa75c07)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[RemoteSpecification] Fail gracefully when deps is an array of array of string
Instead of containing Gem::Dependency objects
### What was the end-user problem that led to this PR?
The problem was some gems have invalid gemspecs served by RubyGems.org. See https://github.com/bundler/bundler/issues/5797.
### Was was your diagnosis of the problem?
My diagnosis was (very old) some gemspecs can have `s.dependencies = [["name", "req"]]` instead of `s.dependencies = [Gem::Dependency.new("name", "req")]`.
### What is your fix for the problem, implemented in this PR?
My fix coerces the invalid dependencies to an array of dependency objects so we can fail more gracefully during installation, without spitting out the error template.
Closes #5797.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows resolution to finish, and falls back upon existing error messages.
(cherry picked from commit 5c62240fea87358a2f5aad729fcd27cf71319b4b)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[Settings] Print pretty values for settings as their converted values, rather than strings
### What was the end-user problem that led to this PR?
The problem was `bundle config` would print bool keys as strings (i.e. `true` was printed as `"true"`)
### Was was your diagnosis of the problem?
My diagnosis was we needed to convert the values before formatting them
### What is your fix for the problem, implemented in this PR?
My fix extracts the conversion method, and calls it in `pretty_values_for`
(cherry picked from commit 1018408d64a7b42f4c901b22af7ce3f9a3558120)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add explicit nil proxy arguments - Fixes no_proxy support
### What was the end-user problem that led to this PR?
When the `no_proxy` environment variable is configured it is not being honored and requests for hosts that are present in the list will be sent through the proxy defined via `http_proxy` and `https_proxy`.
Ultimately this means that a user utilizing the `http_proxy`, `https_proxy`, and `no_proxy` environment variables will unable to access an internal RubyGems source.
### Was was your diagnosis of the problem?
The underlying `net-http-persistent` gem currently does not explicitly pass in nil arguments when a host matches a value within `no_proxy`, so when `Net::HTTP.new()` is called, it will fall back an utilize the values defined in `http_proxy` and `https_proxy`.
https://github.com/drbrain/net-http-persistent/pull/88 has been submitted to add the explicit nil argument to be defined.
### What is your fix for the problem, implemented in this PR?
Adding explicit nil arguments for the proxy definition for `Net::HTTP.new()` as defined by the documentation.
https://ruby-doc.org/stdlib-2.4.1/libdoc/net/http/rdoc/Net/HTTP.html#method-c-new
### Why did you choose this fix out of the possible options?
Per the discussion in https://github.com/bundler/bundler/issues/5781, as Bundler is currently stuck to v2.9.4 of `net-http-persistent` for now, it would be best addressed by a change to the vendored code.
A PR has been submitted to `net-http-persistent` which can be pulled into Bundler when v3.x will be integrated.
(cherry picked from commit 4dfff8be27b6582052c24fd58de46bf14763b83c)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Completely remove the postit trampoline
### What was the end-user problem that led to this PR?
The problem was the bundler trampoline we tried to introduce never completely worked, it worked even less with bundler installed as a default gem (as we intend to do with RubyGems, like, a year ago), and it worked by doing disgusting things that we couldn't be confident would work under all circumstances.
### Was was your diagnosis of the problem?
My diagnosis was our best bet was to completely remove the trampoline from bundler itself.
We intend to address the user story of switching bundler versions in RubyGems directly, where the gymnastics required will hopefully be much less obtrusive. Additionally
### What is your fix for the problem, implemented in this PR?
My fix is to completely delete all references to trampolining / postit from Bundler and admit defeat.
### Why did you choose this fix out of the possible options?
I chose this fix because I'm unwilling to maintain the trampoline any longer, and since it's never been enabled, I feel this is my last chance to pull it from Bundler before I'm stuck maintaining code that doesn't work for all eternity. This will also _finally_ unblock me shipping RubyGems 2.7.
(cherry picked from commit bd95735df25ceac9de8f2186be37079f6cf3d385)
# Conflicts:
# doc/development/SETUP.md
# lib/bundler/postit_trampoline.rb
# spec/other/trampoline_spec.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=colby-swandale
[CLI] Dont print defaults in the command printed with --verbose
### What was the end-user problem that led to this PR?
The problem was that running `bundle lock --verbose` would print
Running `bundle lock --add-platform --remove-platform --verbose` with bundler 1.15.1
even though the platform flags were never specified. This was surfaced by https://github.com/bundler/bundler/pull/5724, which will be fixed by this PR.
### Was was your diagnosis of the problem?
My diagnosis was that default values of options were being printed.
### What is your fix for the problem, implemented in this PR?
My fix is to filter out the default values before getting Thor
### Why did you choose this fix out of the possible options?
I chose this fix because there is no way, within the `CLI` instance, to tell which flags the user has explicitly given, so I felt that filtering out those options that had default values was the next-best thing.
(cherry picked from commit de7d488b833ba30cb6fb7b8a37ebf0367c05c196)
# Conflicts:
# lib/bundler/cli.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
fix a missing space in the group conflict error message
### What was the end-user problem that led to this PR?
There is a typo in the error message that is printed to users when a user specifies a set of conflicting groups when running bundle install. There is a missing space after the first sentence.
```
› bundle install --with foo --without foo
You can't list a group in both, --with and --without.The offending groups are: foo.
```
### Was was your diagnosis of the problem?
execute `bundle install --with foo --without foo`
(cherry picked from commit 69d18afc202f28ceb98f436c25532d02f9d4c1d6)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Update bundle-gem.ronn
Fixed minor typo in Docs. Hope this helps!
(cherry picked from commit be637c55ecae0032d506151364b62c08958e075d)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Create Gemfiles with an HTTPS github source defined
### What was the end-user problem that led to this PR?
The problem was that people are creating new Gemfiles that use the built-in `github` git source, which is being removed in 2.0. Additionally, it does _not_ use an encrypted connection to GitHub.
### Was was your diagnosis of the problem?
My diagnosis was that we can't change the default because of backwards compatibility, but we can encourage _new_ Gemfiles to "do the right thing".
### What is your fix for the problem, implemented in this PR?
My fix is to add our new, recommended definition of the shortcut to all bundler-generated gemfiles.
### Why did you choose this fix out of the possible options?
I chose this fix because it will only affect new Gemfiles.
(cherry picked from commit d11d693e6b1b28b3e873406ff0f29a4c25e8e67e)
# Conflicts:
# lib/bundler/templates/gems.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix headers in contributing README
### What was the end-user problem that led to this PR?
Some headers in contributing/README.md aren't displaying properly.
Also, I promised @indirect that I'd start contributing to bundler last night.
### Was was your diagnosis of the problem?
The markdown was missing some spaces.
### What is your fix for the problem, implemented in this PR?
I added some spaces. TADA!
### Why did you choose this fix out of the possible options?
Adding spaces seemed like the most reasonable choice to transition from a state of non-spaces to a spaceful state.
(cherry picked from commit e9f63050534f2be3f7a468834fb548a1f0d5fc13)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
[Viz] Work correctly when another gem with a graphviz file is present
Closes #5706 by ensuring we always have the correct gem that contains a requirable `graphviz` file loaded (`ruby-graphviz` is the one we test against and suggest installing)
(cherry picked from commit f580c7e3e2fd0525871b25e69f4e7442f35b5660)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[SpecSet] Sort by name in #tsort
Closes #5696
This is required for backwards compatibility, see
issue #5696 for an example. The issue is that previous versions of bundler would have the load path in one (correct) order, and master has them in another (correct) order. So some projects depend on the load path ordering when multiple gems have the same requirable file.
- [x] Test case
(cherry picked from commit e32353b063292427beccdb48fd8d6d0c74555911)
# Conflicts:
# spec/runtime/setup_spec.rb
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
bundler:seg-release-patch-change-version-after-checkout, r=segiddins
[Rakefile] In a patch release, change version after checkout
### What was the end-user problem that led to this PR?
The problem was changes to the versions file on the `master` branch would cause checkout to fail
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=segiddins
[RuboCop] Enable Layout/EmptyLineAfterMagicComment cop
This PR makes cosmetic changes. Layout/EmptyLineAfterMagicComment cop is enabled by default in RuboCop as well.
https://github.com/bbatsov/rubocop/blob/v0.49.1/config/enabled.yml#L203-L206
This PR executed the following command to the source codes.
```console
% rubocop -a --only Layout/EmptyLineAfterMagicComment
```
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Adding process lock for bundle install operations
### What was the end-user problem that led to this PR?
As per #5851 multiple concurrent bundle installs would cause failures when compiling
### What was your diagnosis of the problem?
As described in #5851 a sample project was created demonstrating the issue when running a docker-compose solution of 2 containers using a gem cache volume
### What is your fix for the problem, implemented in this PR?
The fix is to implement an installation process lock so that only one process can execute an install at one time
### Why did you choose this fix out of the possible options?
I chose this fix because it was discussed in #5851 as a possible solution
|
| | |\ \
| | | |
| | | |
| | | | |
add-process-lock
|
| | | | |
| | | |
| | | |
| | | | |
as it seems Ruby 1.8.7 does not unlock on closing of the file
|
