| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
If the compact index returns TooManyRequests, take it easier by
requesting dependencies sequentially instead.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6714: Spec reset state and refactorings r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that while working on #6713, I noticed several issues like order dependent failures, situations hard to debug, or specs doing too much and taking longer than they should.
### What was your diagnosis of the problem?
My diagnosis was that:
* Sometimes specs leak settings and env variable modifications.
* When a hang happens inside a subprocess, it's hard to debug because logging is not printed out anywhere.
* Some specs create unnecessary gemfiles and run `bundle install` multiple times unnecessarily.
### What is your fix for the problem, implemented in this PR?
My fix for state leaks is to reset state after each spec, for the hangs is to reorder some lines in the `sys_exec` helper (https://github.com/bundler/bundler/commit/b305a5b2524a6457b05a9d39e9526f75c98a0752), and for the unnecessary operations, to refactor the specs to avoid them.
### Why did you choose this fix out of the possible options?
I chose this fix because it seems like the best way to alleviate the issues found.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
When working on a bug, I was getting a hang inside the subprocess of a
specs, and it was hard to debug because any logging I added was not
visible. This reording makes logging visible and can make it easier to
troubleshoot these cases.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
If a set of specs need the Gemfile, they also need to `bundle install`
it, so it's more readable to move those together, and also more
efficient since we don't create Gemfiles that are not necessary.
|
| | |
| |
| |
| | |
To make sure we don't leak modified global state.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6773: Fix indentation of bundler executable r=segiddins a=meganemura
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
`bundle binstubs bundler` generates the file like followings.
```ruby
require "rubygems"
m = Module.new do
module_function
def invoked_as_script?
File.expand_path($0) == File.expand_path(__FILE__)
end
(snip)
end
```
### What was your diagnosis of the problem?
My diagnosis was...
the template's `module_function` line is not match to other lines.
### What is your fix for the problem, implemented in this PR?
I fix the template.
### Why did you choose this fix out of the possible options?
no other options.
Co-authored-by: meganemura <meganemura@users.noreply.github.com>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6770: delete merged branches automatically r=hsbt a=indirect
Use a fancy new Bors feature to delete merged branches automatically, hooray.
Co-authored-by: Andre Arko <andre@arko.net>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6769: Fix `remove` when block method appears in gem name r=segiddins a=dduugg
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
https://github.com/bundler/bundler/issues/6768
### What was your diagnosis of the problem?
`remove_nested_blocks` considers any appearance of text matching a block method (`group source env install_if`) to be an occurrence of a nested block.
### What is your fix for the problem, implemented in this PR?
`remove_nested_blocks` should only reduce the scope of where a nested block method can occur.
### Why did you choose this fix out of the possible options?
Another approach would use word delimiters rather than `starts_with?` to find nested block methods, but this is probably fine.
Co-authored-by: Douglas Eichelberger <dduugg@gmail.com>
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
* origin/1-17-stable:
Version 1.17.1 with changelog
Merge #6761
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6761: fix error with path objects in array r=greysteil a=alexggordon
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
The problem was that `Pathname` instances in an array can not be sorted when there are string instances in the array also. Because of this, calling `.sort` before `.to_s` resulted in the error
```
[!] There was an error parsing `Gemfile`: comparison of Pathname with String failed. Bundler cannot continue.
```
you can easily see this issue doing
```
> require 'rails'
=> true
> [Pathname.new("/tmp/bundle")]
=> [#<Pathname:/tmp/bundle>]
> [Pathname.new("/tmp/bundle"), "test"]
=> [#<Pathname:/tmp/bundle>, "test"]
> [Pathname.new("/tmp/bundle"), "test"].sort
ArgumentError: comparison of Pathname with String failed
```
`sort` was called before `map` in the warn message.
We should call `map(&:to_s)` before calling sort, and add a test case for this scenario.
Because it broke our production deploys.
Co-authored-by: Alex Gordon <agordon@sessionm.com>
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6764: Remove unnecessary stuff from specs r=colby-swandale a=deivid-rodriguez
I wrote this patch a while ago but I didn't propose it because I didn't think it would be accepted. Now I think we're ready.
### What was the end-user problem that led to this PR?
The problem was that the specs have a lot of conditional behavior on `Gem::VERSION`.
### What was your diagnosis of the problem?
My diagnosis was that this was necessary because of testing against a big range of rubygems versions on the latest stable branch.
### What is your fix for the problem, implemented in this PR?
My fix is to remove all the conditionals since we'll no longer test against rubygems versions that old on the latest stable, once #6763 lands.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes test code simpler.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |/ / /
| | |
| | |
| | | |
Since we no longer test against rubygems versions that old.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6761: fix error with path objects in array r=greysteil a=alexggordon
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was that `Pathname` instances in an array can not be sorted when there are string instances in the array also. Because of this, calling `.sort` before `.to_s` resulted in the error
```
[!] There was an error parsing `Gemfile`: comparison of Pathname with String failed. Bundler cannot continue.
```
you can easily see this issue doing
```
> require 'rails'
=> true
> [Pathname.new("/tmp/bundle")]
=> [#<Pathname:/tmp/bundle>]
> [Pathname.new("/tmp/bundle"), "test"]
=> [#<Pathname:/tmp/bundle>, "test"]
> [Pathname.new("/tmp/bundle"), "test"].sort
ArgumentError: comparison of Pathname with String failed
```
### What was your diagnosis of the problem?
`sort` was called before `map` in the warn message.
### What is your fix for the problem, implemented in this PR?
We should call `map(&:to_s)` before calling sort, and add a test case for this scenario.
### Why did you choose this fix out of the possible options?
Because it broke our production deploys.
Co-authored-by: Alex Gordon <agordon@sessionm.com>
|
| |/ / / |
|
| |\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 1-17-stable: (38 commits)
Version 1.17.0 with changelog
Merge #6754
Version 1.17.0.pre.2 with changelog
fix failing bundle remove specs
Still document the `--force` option
scope specs testing bundler 2 deprecations to bundler 1 only
Merge #6718
Merge #6707
Merge #6702
Merge #6316
Auto merge of #6447 - agrim123:agr-update-error-message, r=segiddins
Auto merge of #6513 - agrim123:agr-bundler-remove, r=indirect
Auto merge of #6318 - jhawthorn:fix_incorrect_test_in_requires_sudo, r=segiddins
Auto merge of #6450 - bundler:segiddins/bundle-binstubs-all, r=colby-swandale
Auto merge of #6024 - gwerbin:custom-user-bundle-dir, r=colby-swandale
Version 1.17.0.pre.1 with changelog
Auto merge of #5964 - bundler:colby/deprecate-viz-command, r=segiddins
Auto merge of #5986 - bundler:seg-jobs-count, r=indirect
Auto merge of #5995 - bundler:seg-gvp-major, r=indirect
Auto merge of #5803 - igorbozato:path_relative_to_pwd, r=indirect
...
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6754: Add docs for configuring bundler folders through ENV vars r=colby-swandale a=colby-swandale
### Overview
This PR is just adding documentation for the feature in #6024.
Co-authored-by: Colby Swandale <me@colby.fyi>
(cherry picked from commit 97a0430885b370f9a5e1b647a0679be51dc3e20d)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Only mention `--redownload` as an alias of it.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6718: Correct `bundle show` deprecation r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was `bundle show` deprecation messages are incorrect:
```
$ bundle show yard
[DEPRECATED FOR 2.0] use `bundle list` instead of `bundle show`
Resolving dependencies...
/home/deivid/Code/activeadmin/.bundle/ruby/2.5.0/gems/yard-0.9.16
$ bundle list yard
ERROR: "bundle list" was called with arguments ["yard"]
Usage: "bundle list"
```
### What was your diagnosis of the problem?
My diagnosis was that deprecation messages only mention `bundle list`, but in some cases, the replacement is `bundle info`.
### What is your fix for the problem, implemented in this PR?
My fix is to replace "show" in the original command with the appropriate alternative in each case.
### Why did you choose this fix out of the possible options?
I chose this fix because it was the most user friendly message, since it prints the exact command the user needs to type to get rid of the warning.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 703b663a862aeada82169ecf183751616d61a268)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6707: Run more assertions in more cases r=deivid-rodriguez a=deivid-rodriguez
I noticed a couple of places where assertions were being excluded and they shouldn't:
* One was introduced by me in #6702, where the specs added (and some already present) started being tested only on bundler 2.x.
* The other one was introduced in f7414bcb17fe1bd67246021251b5f0527bd6afd1, where one assertion would be run only if a certain env variable was not set. I think it was because of a TravisCI environmental issue that now seems fixed.
My diagnosis was that none of these exclusions are necessary.
My fix is to restore the excluded assertions to all environments and branches.
I chose this fix because it seems best to avoid future problems.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 3d9e6167a7df9ca89a030dfe95c7cdff293e74a9)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6702: Better `--force` to `--redownload` transition r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was. that, while trying to run `bundle install --force` today, I was getting the error `unknown switch --force` error, and I was not sure what was causing it and what I needed to do to fix it. Also, running `bundle install --help` would show `--force` as a supported option, so that would make things even more confusing.
### What was your diagnosis of the problem?
My diagnosis was that:
* A lot of removal/renaming of options in bundler 2 are artificially linked to the `forget_cli_options` switch. To me, those changes even though they are related (stopping rememebering cli options prompted us to actually remove some unnecessary ones), they are independent, so it's not straighforward to find out that it's the `forget_cli_options` setting causing this rename to be in place.
* We should show a helpful deprecation message instead of a hard error, so the transition is easier for users.
* We should update the commands help to document newer instead of deprecated options.
* The `bundle update` command has an equivalent `--force` option that should be renamed too for sanity.
### What is your fix for the problem, implemented in this PR?
My fix to the above problems is to:
* Always keep the `--force` alias, independently of whether the `forget_cli_options` is set or not.
* Show a deprecation message when `--force` is used in bundler 2, but still keep it working as before.
* Update the commands help to use `--redownload`.
* Make the equivalent changes to the `bundle update`
### Why did you choose this fix out of the possible options?
I chose this fix because it seems like the more user friendly way going forward in my opinion.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 16ebc8105b333e055e44711df59e0d42e88963ce)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6316: Display reason to require sudo r=colby-swandale a=okkez
This is useful for non-interactive installation with bundler.
### What was the end-user problem that led to this PR?
https://github.com/treasure-data/omnibus-td-agent/issues/166
I could not notice that bundler needs sudo privilege from logs.
So I checked bundler code.
### What was your diagnosis of the problem?
Bundler does not show the reason to need sudo privilege.
### What is your fix for the problem, implemented in this PR?
Display reason to require sudo.
### Why did you choose this fix out of the possible options?
If bundler displays reason to require sudo, we can notice permission problems as soon as possible.
Co-authored-by: Kenji Okimoto <okimoto@clear-code.com>
(cherry picked from commit 1bd53e3d930e4f915db5536c68b1ed7282304045)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Update error message on bundle add in case of duplication
### What was the end-user problem that led to this PR?
If the user tries to add a gem giving version requirement then bundler throws an error if the gem is already present.
### What was your diagnosis of the problem?
The error displayed is very descriptive but if the user is specifying a gem version maybe he wants to update the gem.
### What is your fix for the problem, implemented in this PR?
Added an instructive message to inform the user that gem can also be updated.
### Why did you choose this fix out of the possible options?
This seemed to be the best informative message.
Closes #6341
(cherry picked from commit 25b76e5e12f861c4f75e726d993d5ba55810deef)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add `bundle remove`
Features of the command implemented:
- Multiple gems support
```bash
$ bundle remove rack rails
```
- Remove any empty block that might occur after removing the gem or otherwise present
Things yet to implement:
- Add `rm` alias. _Optional_
- [x] Add `--install` flag to remove gems from `.bundle`.
- [x] Handling multiple gems on the same line.
- [x] Handle gem spec
- [x] Handle eval_gemfile cases ([one](https://github.com/bundler/bundler/pull/6513#discussion_r195632603) case left)
Closes #6506
(cherry picked from commit 431a3f76868bdb9d4c94be25b28b0c7f26ee9f6e)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Check correct paths are writable in requires_sudo?
### What was the end-user problem that led to this PR?
Bundler was attempting to use `sudo`, despite having permissions to create `bundle_path` (which didn't yet exist).
For some reason this became an issue in recent versions of bundler, where it wasn't one before. I'm not sure what change caused this problem to be exposed since `requires_sudo?` has not changed in a while.
### What was your diagnosis of the problem?
`requires_sudo?` checks that bundle_path, and directories that bundler may need to write within it are writable. If bundle_path itself does not exist, we instead find the nearest existent parent directory, and check that that exists.
Unfortunately, when these two rules were applied together, we got the wrong result. If `bundle_path` did not exist, bundler would check that the nearest parent directory **and everything within that parent directory** were writable. This could lead to false positives for `requires_sudo?` when `bundle_path` did not yet exist.
### What is your fix for the problem, implemented in this PR?
This commit fixes the issue by always checking the writability of `$bundle_path/*` instead of `$parent_path/*`.
### Why did you choose this fix out of the possible options?
If we are able to create `bundle_path`, we know that we can write to anything within it. Changing the test to use `Dir["$bundle_path/*"]` is a succinct way to implement this since it will return `[]` if `bundle_path` does not yet exist.
(cherry picked from commit 948771063c05a56af8888acf5c01171293371214)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[Binstubs] Add --all options
### What was the end-user problem that led to this PR?
The problem was we have removed the `--binstubs` argument to `bundle install`, so saying "oh well, lets install all the bin stubs" became more tedious, requiring multiple calls to `bundle binstubs` and probably some swearing since you forgot what gem contains what binstub.
### What was your diagnosis of the problem?
My diagnosis was we need a one-liner to generate bin stubs for all gems.
### What is your fix for the problem, implemented in this PR?
My fix adds such an option to `bundle binstubs`!
### Why did you choose this fix out of the possible options?
I chose this fix because it keeps binstub generation in its own command, rather than continuing to piggy-back off of `install`
(cherry picked from commit e5c06862a620b8e0bc778164f0e426f927c10cba)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Allow user to override ~/.bundle with environment variables
### What was the end-user problem that led to this PR?
As in #4333, users wanted a way to make Bundler respect the XDG specification.
### What was your diagnosis of the problem?
The directory `~/.bundle` was hard-coded and could not be configured.
### What is your fix for the problem, implemented in this PR?
Allow users to configure `~/.bundle` and its relevant sub-directories by setting environment variables. The environment variables and their fallbacks are as follows:
| variable | fallback if unset |
|---|---|
| `BUNDLE_USER_HOME` | `$HOME/.bundle` |
| `BUNDLE_USER_CACHE` | `$BUNDLE_USER_HOME/cache` |
| `BUNDLE_USER_CONFIG` | `$BUNDLE_USER_HOME/config` |
| `BUNDLE_USER_PLUGIN` | `$BUNDLE_USER_HOME/plugin` |
### Why did you choose this fix out of the possible options?
Unlike https://github.com/bundler/bundler/pull/5787, This solution is not specific to the XDG specification. Users have all kinds of setups, and this is a very general system for allowing them to configure their development machines however they need. It tries to keep all files created by Bundler in the same place (as per https://github.com/bundler/bundler/pull/5787#issuecomment-310154273), but allows the user to override that convention _if they really want to and they know what they are doing_.
If they want to use XDG for everything, they can do it by explicitly setting the `BUNDLE_USER_*` variables to the equivalent `XDG_DATA_*`. If they just want to get `.bundle` out of their home directory, they can do it by setting `BUNDLE_USER_HOME` and don't have to mess with the more specific env variables if they don't want to.
To me, this solution strikes the right balance between "fine-grained control for power users" and "simple, sane defaults for everyone else".
Please let me know if my tests can be improved. My only Ruby experience so far has been writing Homebrew formulas and configuring Jekyll, so I'm sure I have a lot to learn.
(cherry picked from commit e6cc7a24d5ca9da842aeefd23167be4d850c9aa5)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
deprecate the bundle viz command
The `bundle viz` command is to been removed from bundler 2 and extracted into a plugin
Closes #5180
Deprecate the `bundle viz` command with an error explaining that a new gem will replace it's functionality.
(cherry picked from commit dbb0aede6f16e1a252f9a49b48673bfc30bd1242)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[2.0] Auto-configure job count
Closes https://github.com/bundler/bundler/pull/5808.
The description of that issue, copied verbatim:
This argument comes in two parts, but luckily, the first one is both easier to understand and hopefully to agree with.
Background: Bundler 1.4.0 added support for parallel installation via the `--jobs` param. Soon after, [this blog post](http://archlever.blogspot.com/2013/09/lies-damned-lies-and-truths-backed-by.html) (probably greatly amplified by [this Thoughtbot blog post](https://robots.thoughtbot.com/parallel-gem-installing-using-bundler)) popularized the recommendation "set `--jobs` to `nproc - 1`".
Not long after, probably also inspired by the popularity of this tip, this "n - 1 jobs" advice got codified into Bundler itself: https://github.com/bundler/bundler/commit/66acd02de593a6c7ee271bcbce3917eb3a01825a
However, my assertion here is _Bundler should not do that_.
The first argument (the easy one) is just that it's not doing what the user asks for. For all the people following the (seemingly popular) tip to set their jobs to `nproc - 1`, they're actually ending up with the probably-worse `- 2`. Even worse than that, if a user does a conservative `--jobs 2`, they're getting _no benefit_ — Bundler is quietly taking their parallelization back down to "no parallelization".
Hopefully that's a sufficient argument on its own, but the part II is that this blanket advice is probably out-of-date anyway.
Using [this script](https://gist.github.com/tjschuck/ca1d37a8869d1cc01313171b4b318094), I repeatedly installed 29 gems (installing them to a `vendor/` dir and deleting it in between runs). I averaged the time over 10 runs per --jobs value, but the trend holds regardless of how many runs you do.
Note that these numbers are for a machine with 2 physical cores and 4 virtual ones (a Mac, reporting 2 and 4 respectively from `sysctl -n hw.physicalcpu` and `sysctl -n hw.ncpu`, the latter corresponding to Linux's `nproc`).
```
~/Code/tmp/bundler_jobs_bench ☠ ./bundler_jobs_bench.sh
Installing 29 gems repeatedly...
===============================================
Using Bundler version 1.15.1 (current release version)
===============================================
--jobs 1 5.58435780 seconds on average (across 10 runs)
--jobs 2 5.35010690 seconds on average (across 10 runs)
--jobs 3 3.93493610 seconds on average (across 10 runs)
--jobs 4 3.86082760 seconds on average (across 10 runs)
--jobs 5 3.24673650 seconds on average (across 10 runs)
--jobs 6 3.49340190 seconds on average (across 10 runs)
--jobs 7 3.26473430 seconds on average (across 10 runs)
--jobs 8 3.34560500 seconds on average (across 10 runs)
===============================================
Using development version (no more n - 1 jobs)
===============================================
--jobs 1 4.32629540 seconds on average (across 10 runs)
--jobs 2 3.48100690 seconds on average (across 10 runs)
--jobs 3 3.30937880 seconds on average (across 10 runs)
--jobs 4 3.30868200 seconds on average (across 10 runs)
--jobs 5 3.54932920 seconds on average (across 10 runs)
--jobs 6 3.36123440 seconds on average (across 10 runs)
--jobs 7 3.96490630 seconds on average (across 10 runs)
--jobs 8 3.39955640 seconds on average (across 10 runs)
```
From the above, you can see:
1. In the first block, no notable change between `--jobs 1` and `--jobs 2` — that's because they're currently the same.
2. In both, a best time corresponding to the value that (effectively) matches nproc, _not_ nproc - 1.
3. Regardless of nproc coming out best in this run, there is close enough performance among the range of `nproc - 1` through to `nproc * 2` that it doesn't seem like anything in particular (like the `- 1` removed in this commit) should be codified — people seeking to particularly optimize their bundler runtimes should do their own tweaking of the value, and it should be respected as given.
(cherry picked from commit 4d5246d42374192696b89608fc08401f396550bc)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[2.0] [Resolver] Use the GVP for major updates in 2.0
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
The problem was @chrismo wants to start delegating all sorting to the GVP.
My diagnosis was to start doing that in 2.0.
Closes https://github.com/bundler/bundler/issues/5993
My fix adds a feature flag.
(cherry picked from commit a325b6d74f9d8db306f264c43bbe580ec0f1acc8)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Make `install --path` relative to the pwd
### What was the end-user problem that led to this PR?
> I ran the following
>
> bundle install --gemfile=src/main/webapp/WEB-INF/Gemfile --path ./target/bundler/ --standalone
> and it generated the setup file in the following location target/bundler/bundler/setup.rb while it installed the gems in src/main/webapp/WEB-INF/target/bundler/. So it assumed that the --path was relative to the Gemfile instead of the PWD. It also created the .bundle/config in the WEB-INF folder.
Closes #2048
### Was was your diagnosis of the problem?
As discussed on the issue, the path is currently being relative to the Gemfile instead of the cwd.
### What is your fix for the problem, implemented in this PR?
Making the path relative to the cwd if the new feature flag `path_relative_to_cwd` is set t true.
### Why did you choose this fix out of the possible options?
This work was started by @agis (https://github.com/agis/bundler/commit/1da8a7021bdd9bbe76398dddec8bc499655666dd).
(cherry picked from commit 406cdc44bcafd0d89820da0c3b039d08b31db67e)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add registered plugin events for before-all, before, and after gem install
Depends on #6548
### What was the end-user problem that led to this PR?
We only had one plugin hook, which limited the plugin's capabilities a lot.
This adds more
### What was your diagnosis of the problem?
We need more plugin hooks for gem stuff
### What is your fix for the problem, implemented in this PR?
Add more hooks in after-all (including dependencies) and before/after (including install spec)
### Why did you choose this fix out of the possible options?
These seemed like the obvious spots to put the hooks, but I could be wrong. The passed objects also seem to include all the info we need to action on the installations (errors, etc)
(cherry picked from commit f9edd94ed088395ab4ea67d8a6a89a840384214b)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Make all plugin events registered to make documenting them easier
# What?
Every event in #hook and #add_hook will check if the event is registered in
Bundler::Plugin::Events. This allows for easy tracking of what's calling events,
and allow documentation to easily point to a single location.
It also makes testing easier as events are predicatable and accessible via constants
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
---
### What was the end-user problem that led to this PR?
There wasn't really a problem, but this makes adding events easier
### What was your diagnosis of the problem?
Events are not tracked or documented well, this makes them documented well
### What is your fix for the problem, implemented in this PR?
Add an Events registration that hooks test for
### Why did you choose this fix out of the possible options?
Constants make things easily accessible via code, the hash makes it easy to check (with `O(1)` access!) for an event based on value as well.
(cherry picked from commit 3d829081f92b15cbb30cfb17eb5f87dee4a91b6e)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add gemfile flag to exec command
### What was the end-user problem that led to this PR?
This PR resolves the issue #5924
### What was your diagnosis of the problem?
- added a `gemfile` flag in `cli.rb`
- if `options[:gemfile]` is set I created a SharedHelper method `custom_gemfile` which used the predefined `find_file` function to find and set the environment variable with the argument provided
(cherry picked from commit c4892480aba36d31a3b6e232f17a705aaad1b730)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=colby-swandale
[Settings] Append the ruby scope on Bundler 2 with a global path setting
### What was the end-user problem that led to this PR?
The problem was `bundle config path` behaving differently depending on whether the config is local or global was... confusing.
Closes https://github.com/bundler/bundler/issues/6619#issuecomment-405460114.
### What was your diagnosis of the problem?
My diagnosis was setting the `path` setting should be consistent, regardless of the level of configuration it is set at.
### What is your fix for the problem, implemented in this PR?
My fix appends the "ruby scope" to the path when set globally on Bundler 2.
### Why did you choose this fix out of the possible options?
I chose this fix because it means users won't have to re-install gems when switching rubies with a global `BUNDLE_PATH` set.
(cherry picked from commit 0fc64a60b9dfe2f5275f6001a34ea2bf078fd12c)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[bundle list] add `--without-group` and `--only-group`
Listing gems according to groups, either excluding a particular or from a specific group.
Usage:
```bash
bundle list --without-group dev
```
```bash
bundle list --only-group dev
```
Addresses #6564
(cherry picked from commit 25bcb86eb3e0fe8dd18a7b42728d4eda9554beec)
|
