| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7002: Respect color option when instantiating shells r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs have started to fail randomly in several unrelated PRs. See for example, https://travis-ci.org/bundler/bundler/jobs/500322731. Note that currently bundler specs always run in the same order ( :crying_cat_face: ), but enabling or disabling specs can still affect the final set of specs, and thus make this issue manifest.
### What was your diagnosis of the problem?
My diagnosis was that the base thor's shell is being memoized the first time bundler instantiates a shell. That means further instantiations will not respect the "--no-color" option.
### What is your fix for the problem, implemented in this PR?
My fix is to reset the base thor's shell the proper color / non-color one, every time we instantiate a new shell, not only when "--color" is given.
### Why did you choose this fix out of the possible options?
I chose this fix because it felt like a real issue that should be fixed in lib/, and not only with some state resetting hack inside the specs.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| | |
ANSI codes don't work there.
|
| | |
| |
| |
| | |
For consistency.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thor's base shell will be memoized the first time it is set. So if we
instantiate a no-color shell first, further instantiations of a bundler
shell will be initialized with a no-color shell by default. This is
caused some sources specs to fail, depending on the order they run.
See for example https://travis-ci.org/bundler/bundler/builds/500328994.
What we do to fix it is to reset the shell unless no-color is explicitly
specified. That way, further instantiations will rerun thor's internal
logic to choose the default shell.
|
| | |
| |
| |
| |
| | |
The builtin thor's color shell already checks this before printing, and
if not a tty, prints just the string without added color codes.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7203: Fix typo r=deivid-rodriguez a=biow0lf
Co-authored-by: Igor Zubkov <igor.zubkov@gmail.com>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 2-0-stable: (89 commits)
fix changelog 2.0.2 typos
add v2.0.2 changelog
bump version to 2.0.2
Merge #7199
fix bug where bundler v3 is running a test for bundflet 2
Merge #6798
add bors configuation
port GemHelper from master
Merge #7080
Merge #7089
Merge #7068
Merge #7036
Merge #7067
change Bundler 3 specs in travis to use RubyGems 3.0.3
bump RubyGems v3 to the latest version on Travis
Merge #6963
Merge #7078
Merge pull request #7061 from bundler/fix_circular_requires
Merge #6864
remove linting step in travis (it will still run in each build)
...
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7199: Allow `rake release` to ask for input (3rd take) r=colby-swandale a=deivid-rodriguez
This PR supersedes #7108 and #7005.
It fixes #6854.
### What was the end-user problem that led to this PR?
The problem was that if users has 2FA authentication on their rubygems account, `rake release` doesn't really work at the moment, since it hangs asking for the OTP code, but without letting the user know.
### What was your diagnosis of the problem?
My diagnosis was that we need to allow the `rake release` helper that shells out to `gem push` to read `gem push` output and show it to the user, so that she can introduce the requested information.
### What is your fix for the problem, implemented in this PR?
My fix is inspired by @segiddins's comment in https://github.com/bundler/bundler/issues/6854#issuecomment-450536844. `Kernel#system` works like we would expect in this situation.
### Why did you choose this fix out of the possible options?
I chose this fix because #7108 had a few problems:
* It would update the `sh` helper, which is used in many different places. This was unnecessary since most of the times we shell out to the `gem` CLI we don't need to ask for input, and it also produced a very verbose output in those cases, since everything the `gem` CLI prints to the screen would be printed by the bundler helpers too. This PR does not change the current output, other than for `rake release`.
* It would print _duplicate_ output. This is a `rake release` test using #7108:
```
$ RUBYOPT="-I../bundler/lib" ../bundler/exe/bundle exec rake release
Successfully built RubyGem
Name: rake_release_tester
Version: 0.1.0
File: rake_release_tester-0.1.0.gem
rake_release_tester 0.1.0 built to pkg/rake_release_tester-0.1.0.gem.
v0.1.0
Tag v0.1.0 has already been created.
Pushing gem to https://rubygems.org...
You have enabled multi-factor authentication. Please enter OTP code.
Code: asd
Your OTP code is incorrect. Please check it and retry.
rake aborted!
Pushing gem to https://rubygems.org...
You have enabled multi-factor authentication. Please enter OTP code.
Code: Your OTP code is incorrect. Please check it and retry.
/home/deivid/Code/bundler/lib/bundler/gem_helper.rb:187:in `sh'
/home/deivid/Code/bundler/lib/bundler/gem_helper.rb:109:in `rubygem_push'
/home/deivid/Code/bundler/lib/bundler/gem_helper.rb:70:in `block in install'
/home/deivid/Code/bundler/lib/bundler/cli/exec.rb:69:in `load'
/home/deivid/Code/bundler/lib/bundler/cli/exec.rb:69:in `kernel_load'
/home/deivid/Code/bundler/lib/bundler/cli/exec.rb:28:in `run'
/home/deivid/Code/bundler/lib/bundler/cli.rb:468:in `exec'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/home/deivid/Code/bundler/lib/bundler/cli.rb:26:in `dispatch'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/home/deivid/Code/bundler/lib/bundler/cli.rb:17:in `start'
../bundler/exe/bundle:30:in `block in <main>'
/home/deivid/Code/bundler/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
../bundler/exe/bundle:22:in `<main>'
Tasks: TOP => release => release:rubygem_push
(See full trace by running task with --trace)
```
This is the same test using this PR:
```
$ RUBYOPT="-I../bundler/lib" ../bundler/exe/bundle exec rake release
rake_release_tester 0.1.0 built to pkg/rake_release_tester-0.1.0.gem.
Tag v0.1.0 has already been created.
Pushing gem to https://rubygems.org...
You have enabled multi-factor authentication. Please enter OTP code.
Code: asdfasdf
Your OTP code is incorrect. Please check it and retry.
```
* Previous approach was hard to test. The test included here might not be great but it's something...
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit cd05f13a74ef2556823be48c23feaf509c3b1de7)
|
| | |\ \
| | | |
| | | | |
Merge #6798 into `2-0-stable`
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6798: Use https in the Github shortcut by default in Bundler 2 r=colby-swandale a=colby-swandale
This PR is setting Git gems to be fetched over https by default.
Note: This PR is successing #6791
Closes #6785
Co-authored-by: Colby Swandale <me@colby.fyi>
(cherry picked from commit cf45792213fadf97f7aa6464de8ebd79f09725d2)
|
| | |\ \
| | | |
| | | | |
Backport `GemHelper` changes for #7108
|
| | | | | |
|
| | |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7080: Always pass the `--all` flag when needed r=deivid-rodriguez a=deivid-rodriguez
The problem was that some specs were still using `bundle update` to update all gems, which is deprecated.
My fix is to update all specs to use the new preferred command, namely, `bundle update --all`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 63cc70aa2573345ebfb6bddaeef0b9d465591dd9)
(cherry picked from commit e423c83f1f6bccbfc992bca7aef2ad31d6449d75)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7089: Normalize file URIs in spec's lockfiles r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that bumping bundler's version in #7088 made a lockfile spec fail.
### What was your diagnosis of the problem?
My diagnosis was that there was a combination of bugs that was making this spec pass, but the spec was incorrect.
### What is your fix for the problem, implemented in this PR?
My fix is to change the test version the spec uses to not hit https://github.com/rubygems/rubygems/issues/2595, and thus reproduce the failure. And then fix the spec that was incorrect because the lockfile written had different URLs (`file://localhost/<stuff>`) from the lockfile we were checking against (`file://<stuff>`), thus tricking `bundle install` into thinking something had changed, and thus making it rewrite it with an incorrect bundler version.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes #7088 pass and it reduces surprises.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 4cae424d604cbeb8ee84127a6b8896c45e7e2c84)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7068: Bump vendored fileutils to 1.2.0 r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was we manually updated some code in the vendored fileutils instead of using a released version.
### What was your diagnosis of the problem?
My diagnosis was that we should use the recently released fileutils 1.2.0.
### What is your fix for the problem, implemented in this PR?
My fix is to vendor it through `bin/rake vendor:fileutils[v1.2.0]`.
### Why did you choose this fix out of the possible options?
I chose this fix because it properly upgrades the vendored code to match what's last released.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 2167156db020fbe6ce74759cbf62ad1ceb651fb7)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7036: Bump travis rubies r=hsbt a=deivid-rodriguez
The problem was that hacks create confusion, even if they include TODO notes.
My diagnosis was that we can should upgrade to the latest ruby releases to reduce the number of hacks we need to maintain.
My fix is to upgrade rubies and remove hacks.
I chose this fix because it's a good change.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit d368aa9e6257a27fab31efe0396069c8977cdc99)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7067: Tweaking vendoring r=hsbt a=deivid-rodriguez
The problem was that we were not using the latest versions of some of our vendored dependencies.
My diagnosis was that we should upgrade them.
My fix is to upgrade them using `automatiek`, and add a few tweaks to our vendoring setup.
I chose this fix because.... I didn't really considered other options.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 6f39ea5b15d61e5bdf7915bc94d66c31b1242d15)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6963: Allow to `bundle exec` default gems r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that since `irb` and others were moved to default gems, users cannot directly use them in a bundler context, unless they add it to their gemfiles. In my opinion, this completely defeats the purpose of default gems, and makes bundler degrade the user experience instead of making it better.
### What was your diagnosis of the problem?
My diagnosis was that when bundler replaces the set of gems known to rubygems, it restricts the world to what's in the Gemfile (or resolved from it), and that doesn't include default gems.
### What is your fix for the problem, implemented in this PR?
My fix is to also include the set of default gems, unless they are already included in the gemfile dependencies.
### Why did you choose this fix out of the possible options?
I chose this fix because it's reasonably simple and I think it shouldn't affect how other parts of bundler function.
Fixes #6929.
Fixes https://bugs.ruby-lang.org/issues/15503.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 3b6c6e35b36fc056ec3610f9f22f1cea2ef0b06f)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7078: Allow `update` to install when `--no-install` used r=colby-swandale a=deivid-rodriguez
Fixes #7077.
### What was the end-user problem that led to this PR?
The problem was #7077. When the `no_install` configuration is activated, this prevents `bundle update` from installing gems, but `no_install` is only meant to affect `bundle package`.
### What was your diagnosis of the problem?
My diagnosis was that `bundle update` needs to ignore this setting.
### What is your fix for the problem, implemented in this PR?
My fix is to the same `bundle install` does to fix this problem.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the most straightforward solution, although the handling of this flag could probably use some refactoring.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 91912a1da92a5c1d0c6c29b03f35ed4fc024021f)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Fix circular require warnings
(cherry picked from commit aaa0b0ce6a447aa0f01301799f3163832da6566d)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6864: Include URL in Bundler::Fetcher::FallbackError message for Net::HTTPNotFound r=segiddins a=greysteil
### What was the end-user problem that led to this PR?
It was really painful to debug persistent NotFound errors, as it wasn't clear where they were coming from,
### What was your diagnosis of the problem?
Bundler was obfuscating the URL that wasn't found unnecessarily.
### What is your fix for the problem, implemented in this PR?
My fix is to add the URL to the `Bundler::Fetcher::FallbackError` message for `Net::HTTPNotFound` errors.
### Why did you choose this fix out of the possible options?
I chose this fix because it was simple and easy to test.
Co-authored-by: Grey Baker <greysteil@gmail.com>
(cherry picked from commit 4557124b5ea30821895eb2686874cb4219f404e2)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6948: Bump rubygems to 3.0.2 and ruby to 2.6.1 in TravisCI r=deivid-rodriguez a=deivid-rodriguez
The problem was that I have some spec failures locally, and they don't seem to be reproduced in TravisCI.
My diagnosis was that either my environment is messed up or there's some issues with the latest rubygems + ruby combination.
My fix is to use latest rubygems and ruby in Travis, so I can double check whether the problem is just my environment or a real problem.
I chose this fix because it's always good practice to test against the latest versions of your dependencies.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 0ca2f4ea781abf697c484df6ba26feeded744854)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6952: Bump TravisCI build to Xenial r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that CI in #6938 is failing, and I'm not sure why.
### What was your diagnosis of the problem?
My diagnosis was that I should split the two changes made in that PR to find out the culprit.
### What is your fix for the problem, implemented in this PR?
My fix is to split the TravisCI update to xenial, because my guess is that this is not the culprit, so if the build is green, we can merge this and upgrade :tada:
### Why did you choose this fix out of the possible options?
I chose this fix because it means no work for me, just delegate to TravisCI. :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 1a63384c807f164bfc2fe26ce34ac781a974c7e6)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
update rubocop to 0.50
This PR just updates rubocop to 0.50
(cherry picked from commit 0a672a1deb01fa4ce8b51eb2f5b545692c64cd83)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6948: Bump rubygems to 3.0.2 and ruby to 2.6.1 in TravisCI r=deivid-rodriguez a=deivid-rodriguez
The problem was that I have some spec failures locally, and they don't seem to be reproduced in TravisCI.
My diagnosis was that either my environment is messed up or there's some issues with the latest rubygems + ruby combination.
My fix is to use latest rubygems and ruby in Travis, so I can double check whether the problem is just my environment or a real problem.
I chose this fix because it's always good practice to test against the latest versions of your dependencies.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 0ca2f4ea781abf697c484df6ba26feeded744854)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6935: Make URLs in document consistent and secure r=greysteil a=aeroastro
There are 3 documentation problems
* End-users experience 301 redirect when visiting http://www.bundler.io and http://bundler.io
* End-users might accidentally send email addresses via http version of https://slack.bundler.io, which is not redirected automatically.
* Partially fixing this is O.K., but consistent URLs throughout the documentation are easy to use.
I have manually visited the Slack invitation URL on https://bundler.io/ and noticed the problem.
Following are the simple curl command to explain this problem.
```
$ curl -I http://slack.bundler.io
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 3726
Etag: W/"QPm3qygnJrqeFm+KK+VifA=="
Date: Mon, 28 Jan 2019 07:32:02 GMT
Via: 1.1 vegur
```
```
$ curl -I http://www.bundler.io
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://bundler.io
X-Redirector-Version: 84a0a5c
Date: Mon, 28 Jan 2019 07:32:28 GMT
```
```
$ curl -I http://bundler.io
HTTP/1.1 301 Moved Permanently
Server: GitHub.com
Content-Type: text/html
Location: https://bundler.io/
X-GitHub-Request-Id: FF7E:37F3:4DD47F:595032:5C4EB012
Content-Length: 178
Accept-Ranges: bytes
Date: Mon, 28 Jan 2019 07:32:35 GMT
Via: 1.1 varnish
Age: 0
Connection: keep-alive
X-Served-By: cache-nrt6127-NRT
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1548660755.461639,VS0,VE91
Vary: Accept-Encoding
X-Fastly-Request-ID: 8c832766ee3154dc26abd3e1adcd1258a243e4ce
```
My fix is to replace old URLs with new URLs.
* Replace Slack invitation URLs with safe https ones
* Replace http://www.bundler.io with https://bundler.io
* Replace http://bundler.io with https://bundler.io
Because rewriting URLs on document is easy and simple.
Optionally, if someone could implement 301 redirect on Slack invitation URL, it would further help the issue.
Co-authored-by: Takumasa Ochi <aeroastro007@gmail.com>
(cherry picked from commit 2b8015c2aa696209526f5747d09ee41f48553d46)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6926: Move Rubocop development dependency into gemspec r=hsbt a=alyssais
The problem was that tools like RubyGems.org or Bundix that use the gemspec as the source of truth for dependencies didn't pick up on the development dependency on Rubocop.
My diagnosis was that the reason for this, which was that Rubocop had a minimum Ruby version of 2.0.0, was no longer an issue, since Bundler 2 doesn't support Rubies that old anyway.
My fix was to move the Rubocop requirement into the gemspec.
I chose this fix because it addresses the problem I was having, feels right, and the old workaround doesn't look like it's necessary any more.
Co-authored-by: Alyssa Ross <hi@alyssa.is>
(cherry picked from commit e58436ef762ef1120024bbcda2620637f0484547)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6923: Ignore `Object =~` warnings. r=segiddins a=hsbt
### What was the end-user problem that led to this PR?
We faced a lot of warnings with `rake spec` of bundler repository.
### What was your diagnosis of the problem?
Ruby 2.7.0-dev added the warnings for `Object =~` comparison.
### What is your fix for the problem, implemented in this PR?
I added the additional condition and bump a version of the development dependency.
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
(cherry picked from commit e66e6f2fb7d595151bd77a342a07c9cd15e3cac0)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6315: Removed compatibility hack for old rubies. r=hsbt a=hsbt
Nothing.
Bundler will never use them in version 2.
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
(cherry picked from commit 1b2559ab57da944e92f93db61a0a322642cd0b31)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6884: Remove unnecessary condition r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some code in the feature flags implementation seemed uncovered.
### What was your diagnosis of the problem?
My diagnosis was that the code should be either covered or removed.
### What is your fix for the problem, implemented in this PR?
My fix was to remove the code.
### Why did you choose this fix out of the possible options?
I chose this fix because the scenario where that code would get covered is more likely to be unintentional and risk introducing a bug. Defining a feature flag without a default block is the same as don't defining a feature flag and just relying on the default value for the setting. In these circumstances, it's more likely that the developer forgot to include a default block, so letting that case crash would be better, I think.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit ab06ed2e865cb40c75c83bc76bb7161277d6a185)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6805: [Plugin] Ignore the deployment setting r=colby-swandale a=segiddins
### What was the end-user problem that led to this PR?
The problem was installing a new plugin in deployment mode would fail with a suggestion the lock file was corrupted, when it installed fine without deployment mode.
Fixes #6795.
### What was your diagnosis of the problem?
My diagnosis was deployment mode was interfering with installing a new plugin.
### What is your fix for the problem, implemented in this PR?
My fix overrides the deployment and frozen settings when creating the plugin Definition.
### Why did you choose this fix out of the possible options?
I chose this fix because having a "frozen" plugin bundle makes no sense, since plugins aren't written to the lockfile.
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
(cherry picked from commit 07d22aebd892b1b0ee8e3829bec57abb13864981)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6806: Todo remove require for Bundler 2.0 r=colby-swandale a=gavrieltal
Co-authored-by: Gavriel Loria <gtloria@protonmail.com>
(cherry picked from commit c9dca0d6c6fafc9569caa2b42830f5a2368df368)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6774: [Definition] Dont pin path deps to newer versions r=segiddins a=segiddins
### What was the end-user problem that led to this PR?
The problem was setting `only_update_to_newer_versions` would break using path gems.
Closes #6750
### What was your diagnosis of the problem?
My diagnosis was path gems should _always_ get their version used, since there's 0 alternative versions from a path source.
### What is your fix for the problem, implemented in this PR?
My fix should circuits the list of additional requirements when the dependency's source is a path source.
### Why did you choose this fix out of the possible options?
I chose this fix because it solves the problem in the same place that has the feature flag conditional
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
Co-authored-by: Grey Baker <greysteil@gmail.com>
(cherry picked from commit 60672b40a473d746826c9940763e4597b05d701f)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6790: Fix multiple source warning messages from `error` to `warn` r=greysteil a=jlw
I've been working on a few repos for most of this year that use a privately-hosted gem with the same name (but completely different purpose) as a gem hosted at rubygems.org - whenever I start with a clean copy and `bundle install` for the first time, I am presented with a warning in red that the gem was found in multiple sources. The red text makes me think that something went wrong, even though bundler did exactly what I wanted it to do.
The user experience is wrong - a warning should not be red.
When I looked at the source, I saw immediately that the warning was using `Bundler.ui.error` instead of `Bundler.ui.warn`.
This is a bug fix with a limited lifespan - after setting up a local copy of bundler I see that 2.0's handling of multiple sources A) is smarter and bypasses the error in most of the repos where I saw it with bundler 1.x; and B) fails early with a different error message in the remaining repos.
The fix is simply switching to `Bundler.ui.warn` in this case.
_I didn't see any other possible options._
Co-authored-by: Jeremy Weathers <jeremy@codekindly.com>
(cherry picked from commit f160d15fe4e1cb25fad6a34ed9abd10b21f587f8)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6775: [Plugin::Index] Only register each plugin once for a given hook r=colby-swandale a=segiddins
### What was the end-user problem that led to this PR?
The problem was running `plugin install` twice for a plugin withs hooks would cause that hook to be registered twice.
Closes #6771.
### What was your diagnosis of the problem?
My diagnosis was a plugin's hooks should only be run once per event.
### What is your fix for the problem, implemented in this PR?
My fix is to `uniq` the list of plugins registered for each event.
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
Co-authored-by: Olle Jonsson <olle.jonsson@gmail.com>
Co-authored-by: Colby Swandale <me@colby.fyi>
(cherry picked from commit 05b552ccafb6fc6492e498edaeddd0979657c517)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
(cherry picked from commit 905dce42705d0e92fa5c74ce4b9133c7d77a6fb1)
|
