| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7160: Bump Rubocop version r=deivid-rodriguez a=natesholland
### What was the end-user problem that led to this PR?
There was not a problem, just some housekeeping.
### What was your diagnosis of the problem?
I wanted to see if bumping the latest Rubocop version would bring in any new fixes or updates. It did not but I figured it didn't hurt to bump the version in case new PRs are affected by the new cops.
### What is your fix for the problem, implemented in this PR?
I bumped the patch version of RubCop by 1.
### Why did you choose this fix out of the possible options?
I chose this fix because it was the only logical thing to do.
Co-authored-by: Nate Holland <natesholland@gmail.com>
|
| |/
|
|
|
| |
I was hoping this would turn up new cops or changes. It did not end up
changing anything.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7142: Fully switch to https sources r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that in https://github.com/bundler/bundler/pull/7000 I implemented a plan to migrate to https source by default and deprecate github/gist/bitbucket builtin sources, but I changed my mind and I think it's overkill.
The reasons I changed my mind are:
* We [actually announced the switch](https://bundler.io/blog/2019/01/03/announcing-bundler-2.html) and the fact that it didn't happen was not intented. So this can be considered as fixing a bug.
* We have warned non https git sources for ages
https://github.com/bundler/bundler/blob/a6533c0fe6541cc929f895ee0b7a9b673d34cb4d/lib/bundler/source_list.rb#L144-L153
I think people should be ready by now.
Also, we introduced a new setting `github.https` that seems to do essentially the same thing as `git.allow_insecure`.
### What is your fix for the problem, implemented in this PR?
My fix is to take the initial approach of https://github.com/bundler/bundler/pull/6911 and actually do this in the next release.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7149: Fix bundle update crash r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I introduced a regression with https://github.com/bundler/bundler/pull/6329. When running `bundle update <gem>`, where `<gem>` is included in the Gemfile, but it's for another platform from the current one, `bundle` would crash with the following error:
```
NoMethodError: undefined method `source' for nil:NilClass
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/update.rb:86:in `block in run'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/update.rb:78:in `each'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/update.rb:78:in `run'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:280:in `block in update'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/settings.rb:129:in `temporary'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:279:in `update'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:26:in `dispatch'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:17:in `start'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:21:in `block in <top (required)>'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:13:in `<top (required)>'
/home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `load'
/home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `<main>'
```
### What was your diagnosis of the problem?
My diagnosis was that we can't always rely on the spec being updated not being `nil` in the definition. It can be `nil` for gems in excluded groups, or for gems included only for platforms different from the current one.
### What is your fix for the problem, implemented in this PR?
My fix is to handle this case and show a proper error.
### Why did you choose this fix out of the possible options?
I chose this fix because it's user friendly.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
And show a proper warning. The other case already shows a message
somewhere else ("Gems for group <bla> were not updated/installed"), so I
just skip any warning in that case.
|
| | | |
| | |
| | |
| | | |
We're not saving specs here, actually.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7153: Rename local variables for readability r=deivid-rodriguez a=mtsmfm
Extracted from https://github.com/bundler/bundler/pull/7143#discussion_r279187838
> Also, I would split the variable rename, which is great because it makes the code more readable, to a separate commit
### What was the end-user problem that led to this PR?
No end-user is affected because it's just local var name.
As a bundler contributor, I think it's much easier to understand if we rename them.
When I was investigating https://github.com/bundler/bundler/pull/7143, it's hard to understand what `other` stuff and `deps2` is.
Co-authored-by: Fumiaki MATSUSHIMA <mtsmfm@gmail.com>
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7147: Fix specs with rubygems master installed globally r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was if you have rubygems's master installed globally, bundler specs no longer pass.
### What was your diagnosis of the problem?
My diagnosis was that having rubygems master installed, installs bundler's master as a default gem. That actually makes bundler behave better. In particular, `bundle show` and `bundle licenses` start properly handling the `bundler` gem itself.
### What is your fix for the problem, implemented in this PR?
My fix is to change bundler's code to fix this specs in every situation, and not only when the bundler version being tested is also installed as a default gem.
NOTE: I also included some changes to unify `bundle show` deprecation specs in the file that tests all deprecations.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7148: Use `Gem.add_to_load_path` if available r=hsbt a=deivid-rodriguez
This is a follow up to https://github.com/rubygems/rubygems/pull/2749.
### What is your fix for the problem, implemented in this PR?
My fix is to unify all LOAD_PATH manipulation in a single place, that uses rubygems logic if available.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Since we've moved the whole logic to the integration class.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
And use the rubygems method if available.
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7151: Bump rubocop to 0.68.0 r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that our rubocop version is getting outdated. Also, I added [a PR to rubocop](https://github.com/rubocop-hq/rubocop/pull/6935) so that we can remove the exclusions in our configuration, and it has now been released.
### What is your fix for the problem, implemented in this PR?
My fix is to update rubocop to the latest version, update the configuration, and fix new offenses.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
7150: Proper group skip message for bundle update r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that when `bundle update` skipped groups, it shows a message about "gems not being installed". The message could be better and say "gems not being updated" instead, since that's what the user was trying to do.
### What was your diagnosis of the problem?
My diagnosis was that helper method was reused by the update and the install commands, but its message was specific to install.
### What is your fix for the problem, implemented in this PR?
My fix is to pass a parameter to the method with the calling command, so that the message is customized properly.
### Why did you choose this fix out of the possible options?
I chose this fix because it's easy.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | | |
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | | |
Since it includes stuff for `bundle update` too.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7138: Remove unnecessary `BUNDLER_SPEC_RUN` env variable r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that our library code contains logic that's only necessary for bundler's specs. I think library code should not contain this kind of code, since it affects end users.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the logic, and instead ensure the specs satisfy what the code wanted to ensure (that specs pass even when there's a Gemfile further up in the directory hierarchy outside of the bundler's development copy).
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
7140: Get `bundle exec` respecting proc titles r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundle exec` would not respect custom proctitles inside scripts.
### What was your diagnosis of the problem?
My diagnosis was that the previous code was using the third form of `Kernel.exec`, documented as:
> In the third form (exec(["command", "argv0"], "arg1", ...)), starting a two-element array at the beginning of the command, the first element is the command to be executed, and the second argument is used as the argv[0] value, which may show up in process listings.
See https://ruby-doc.org/core-2.6.3/Kernel.html#method-i-exec.
However, since this form messes with proc titles, it seems to affect scripts settting their own proc titles.
### What is your fix for the problem, implemented in this PR?
My fix is to use the simpler form:
> In the second form (exec("command1", "arg1", ...)), the first is taken as a command name and the rest are passed as parameters to command with no shell expansion.
We were not passing any special proc title, so I don't think we need the third form, and this simpler form allows custom proc titles inside scripts to work just fine.
### Why did you choose this fix out of the possible options?
I chose this fix because I couldn't figure out a better one.
Closes #7135.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
7143: Fix to update conservatively for gemspec update r=deivid-rodriguez a=mtsmfm
Fix https://github.com/bundler/bundler/issues/6967
### What was the end-user problem that led to this PR?
https://github.com/bundler/bundler/issues/6967
### What was your diagnosis of the problem?
My diagnosis was https://github.com/bundler/bundler/blob/ec8f98574a90de1e87a50e00141180d761f161dc/lib/bundler/definition.rb#L806 is loose
### What is your fix for the problem, implemented in this PR?
My fix makes it strict
### Why did you choose this fix out of the possible options?
I think I don't have any other options
Co-authored-by: Fumiaki MATSUSHIMA <mtsmfm@gmail.com>
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
Fix https://github.com/bundler/bundler/issues/6967
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
7063: Small fix with plural. r=deivid-rodriguez a=ryanfox1985
**The problem was** when is outdated is ran always if the gem belongs to one group or more always show "groups" in plural.
**My diagnosis is** if the gem belongs to one group it's incorrect to show "groups" in plural.
**My fix was** if the gem belongs to one group it should show "group" in singular.
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixed rubocop.
Refactors.
Rollback style.
|
| |\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
6928: When a 401 response is received, raise BadAuthenticationError if credentials were present in the request URI r=deivid-rodriguez a=jdliss
### What was the end-user problem that led to this PR?
Some gem servers respond to bad username/password request with a 401 instead of a 403.
### What was your diagnosis of the problem?
When a 401 response was received, bundler would automatically assume no credentials were supplied, leading to a response of
```
Authentication is required for http://moto@gems.motologic.com/.
Please supply credentials for this source. You can do this by running:
bundle config http://moto@gems.motologic.com/ username:password
```
even when a username and password was present in the bundler config.
### What is your fix for the problem, implemented in this PR?
There already exists a check for credentials in the request URI for 403 responses. I took that pattern and implemented it for 401 responses as well.
### Why did you choose this fix out of the possible options?
I chose this fix because a very similar pattern already exists in bundler, I just applied the same logic to another response code.
Co-authored-by: Jonathan <jonacom@lissismore.com>
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
6885: Don't check for the existence of a writable home directory if BUNDLE_USER_HOME is set r=deivid-rodriguez a=jturkel
#6024 added support for specifying an alternate bundler home directory via the `BUNDLE_USER_HOME` environment variable. Unfortunately bundler still checks for a writable user home directory even if the `BUNDLE_USER_HOME` override is specified resulting in warnings like this:
```
`/home/appuser` is not a directory.
Bundler will use `/tmp/bundler/home/unknown' as your home directory temporarily.
```
The fix for this problem is to only evaluate bundler path fallbacks if environment variable overrides are not specified.
Co-authored-by: Joel Turkel <jturkel@salsify.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
BUNDLE_USER_HOME is set
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
7145: More compatibility cleanup r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was we still have unnecessary code for compatiblity with rubygems versions we no longer support.
### What was your diagnosis of the problem?
My diagnosis was that we can remove this code.
### What is your fix for the problem, implemented in this PR?
My fix is to remove it.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
`stubs_for` was introduced with rubygems 2.5.0, the oldest version we
support.
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It's available since rubygems 2.0.
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
7146: Fix typo in file extension r=hsbt a=victorgama
Hi there! I skipped all the questions the template asked, since this is a kinda silly PR. 🌻
Co-authored-by: Victor Gama <hey@vito.io>
|
