summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Migrate git proxy helpers to use Open3replace_git_helpers_with_open3David Rodríguez2019-05-241-30/+22
|
* Merge #7163Bundlerbot2019-05-236-74/+28
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7163: Remove `global_path_appends_ruby_scope` setting r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was we're artificially holding shipping bug fixes like the fact the ruby scope is not included in the install path when `BUNDLE_PATH` is used as an environment variable or global setting. ### What was your diagnosis of the problem? My diagnosis was that we can remove the setting, and that it's fine that affected users rerun `bundle install` to get their installation paths fixed. ### What is your fix for the problem, implemented in this PR? My fix is to remove the setting. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove now unnecessary append_ruby_scope fieldremove_global_path_appends_ruby_scopeDavid Rodríguez2019-05-071-4/+4
| |
| * Remove global_path_appends_ruby_scope settingDavid Rodríguez2019-05-076-71/+25
| | | | | | | | | | | | | | This is a bug fix, so it makes no sense to make it configurable. Also, the fix is unlikely to cause problems other than maybe needing a fresh `bundle install` on some edge cases. So, let's ship the fix and remove the setting.
* | Merge #7174Bundlerbot2019-05-181-0/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7174: Revert "Remove unused filter" r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I removed the `:git` filter from our specs in ac282dc9de5e20db85e9cdf23b97763a2a2cc292 because I thought it was unused, but it's not. ### What was your diagnosis of the problem? My diagnosis was that the filter is actually used once: https://github.com/bundler/bundler/blob/3ec8165eec0a1af8c45ee258d3e7cb61fba875a2/spec/update/git_spec.rb#L162 ### What is your fix for the problem, implemented in this PR? My fix is to revert the commit. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Revert "Remove unused filter"restore_git_filterDavid Rodríguez2019-05-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit ac282dc9de5e20db85e9cdf23b97763a2a2cc292. Because the filter is actually used once: https://github.com/bundler/bundler/blob/3ec8165eec0a1af8c45ee258d3e7cb61fba875a2/spec/update/git_spec.rb#L162 My bad.
* | | Merge #7166Bundlerbot2019-05-1611-16/+30
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7166: Better test specific file searching r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that in #7138 I removed some test specific code from lib, but it's not quite working. ### What was your diagnosis of the problem? My diagnosis was that the mocking I used to fix the issue of bundler looking for files outside of bundler's clone doesn't work inside subprocesses, which many of our specs use. That means some specs were currently failing if you have Gemfile's on `.bundle` folders up in the directory hierarchy ascending from your bundler's clone ### What is your fix for the problem, implemented in this PR? My fix is revert to the previous approach of using a test specific environment variable to prevent search up higher than the test directory when running our specs. ### Why did you choose this fix out of the possible options? I initially tried to monkeypatch the gemfile finding helpers only inside specs, but that caused load order issues (I monkeypatched the helpers insde `support/hax.rb`, that caused the monkeypatched lib code to be loaded _before_ the rest of `bundler`, which caused issues in some specs). Overall, the old approach is the only one that works without issues, so I'm reverting to it, at least for now. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Previous approach for not walking further up from test folderbetter_test_specific_file_searchingDavid Rodríguez2019-05-1611-16/+30
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | I tried monkeypatching the gemfile finder methods in hax.rb, but that resulted in loading parts of bundler too early, and getting redefinition warnings when loading them again from exe/bundle, resulting in actual errors in some cases. The fix for that required eagerly loading the monkeypatched parts of bundler, but that involves changing lib just for the sake of making existing tests pass, and that's what the original changes intend to avoid. So, I'm just reverting to the previous approach of setting an environment variable just for testing and check that. Reverts 11597fef24274bf1542384512faed697d7f41e3b.
* | Merge #7062Bundlerbot2019-05-1230-113/+100
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7062: Remove version overwriting hacks r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we are doing some hacks in our version file that are... dangerous. At very least they cause "circular problems" like #6927, but I also have bad feelings about it. ### What was your diagnosis of the problem? My diagnosis was we're overwriting the version of the currently loaded bundler :grimacing:. This hack is _almost_ unnecessary (see the spec run here with the hack fully removed: https://travis-ci.org/bundler/bundler/builds/509497021. Only three jobs failed, and for old rubies/rubygems/bundler). ### What is your fix for the problem, implemented in this PR? My fix is to limit the hack to `bundler`'s spec run, since it's only needed there. ### Why did you choose this fix out of the possible options? I chose this fix because fully getting the build green with the hack fully removed is a bit of work. I dedicated a bit of time to investigate one of the failures and it all comes down to the priority of loading default gems vs `-I`. So I think something like https://github.com/rubygems/rubygems/pull/1868 should fix it. But that's out of the scope of this PR. Closes #6927. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove version overriding stuffremove_version_overwriting_hacks_from_regular_runtimeDavid Rodríguez2019-05-121-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By doing this we avoid circular requires (`rubygems` requires `bundler` via `USE_GEMDEPS`, `bundler` requires `rubygems` when loading its own version), and also redefinition warnings when the `bundler.gemspec` is evaluated with `rubygems` already loaded (for example, when running `ruby setup.rb` from `rubygems` repo). But most importantly, we avoid leaking from a bundler installation to a different one, something quite common since bundler is a default gem. The previous hack meant acting like that didn't happen, but seems actually quite dangerous. We can do this due to the previous work of making all of bundler internal requires not rely on the LOAD_PATH, and thus making it impossible to leak to another copy of bundler.
| * | Migrate molinillo to use relative requiresDavid Rodríguez2019-05-1212-27/+27
| | |
| * | Migrate thor autoloads to not use LOAD_PATHDavid Rodríguez2019-05-122-6/+6
| | |
| * | Migrate internal autoloads to not use LOAD_PATHDavid Rodríguez2019-05-1211-59/+59
| | |
| * | Setup rubyopt to require bundler absolutelyDavid Rodríguez2019-05-123-4/+5
| | | | | | | | | | | | This way, we will never leak to a different bundler copy.
| * | Add missing requireDavid Rodríguez2019-05-121-0/+2
|/ / | | | | | | | | | | | | Otherwise it could happen that support/hax defines Bundler::VERSION first, and then the real version file redefines it. Not at the moment due to the version overwriting hacks in our version.rb file, but those will be removed.
* | Merge #7156Bundlerbot2019-05-121-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7156: Improve fileutils require r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was there's [upstream changes in fileutils](https://github.com/ruby/fileutils/pull/35). ### What is your fix for the problem, implemented in this PR? My fix is to port the upstream changes, which consist of using `require_relative` everywhere. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Require version relatively in fileutilsimprove_fileutils_requireDavid Rodríguez2019-05-031-1/+1
| | |
* | | Merge #7167Bundlerbot2019-05-101-45/+6
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7167: Minor spec improvements r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that some specs had harcoded paths from @indirect's file system. :sweat_smile:. These lockfiles are clearly incorrect but specs are not failing. ### What was your diagnosis of the problem? My diagnosis is that these lockfiles are unnecessary for these tests and don't affect what these tests are testing. ### What is your fix for the problem, implemented in this PR? My fix is to remove the lockfiles. As a consequence of the change, the "comment numbering" got messed up. So I removed the numbering while keeping the comments to avoid that problem from happening again in the future. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Remove numbering hard to keep up to dateminor_spec_improvementsDavid Rodríguez2019-05-061-5/+5
| | | |
| * | | Remove incorrect lockfiles from sources specsDavid Rodríguez2019-05-061-40/+1
| | |/ | |/| | | | | | | | | | The lock files are not relevant for the tests, and they are incorrect anyways.
* | | Merge #7118Bundlerbot2019-05-091-16/+27
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7118: Refactors to `bundle add` r=deivid-rodriguez a=ryanfox1985 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 no problem just code refactors. ### What was your diagnosis of the problem? My diagnosis was the possibility to reorganize the code to make clean and more readable. ### What is your fix for the problem, implemented in this PR? My fix reorganize the code, good usage of the attributes. Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
| * | Improve if clause.Guillermo Guerrero2019-05-081-1/+1
| | |
| * | Remove if.Guillermo Guerrero2019-04-121-4/+2
| | |
| * | Run method refactors, move to functions.Guillermo Guerrero2019-04-121-9/+21
| | |
| * | Move version to attr_readerGuillermo Guerrero2019-04-121-3/+2
| | |
| * | Add cli refactorsGuillermo Guerrero2019-04-121-9/+11
| | | | | | | | | | | | Move attr_reader variables to avoid @
* | | Merge #7157Bundlerbot2019-05-062-1/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7157: Improve azure configuration r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that failures in Azure are not logged, so it hard to improve the situation. ### What is your fix for the problem, implemented in this PR? My fix is to configure Azure to run until completion without any timeouts, and remove intercepting the global timeout (which we did to make sure build is still green when it times out), because it's no longer necessary. Now we should be able to see the failures on every PR. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Set unlimited running time in Azureimprove_azureDavid Rodríguez2019-05-052-1/+2
|/ / /
* | | Merge #7160Bundlerbot2019-05-051-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | Bump Rubocop versionNate Holland2019-05-051-1/+1
|/ / / | | | | | | | | | | | | I was hoping this would turn up new cops or changes. It did not end up changing anything.
* | | Merge #7142Bundlerbot2019-05-056-96/+27
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Fully switch to https sourceshttps_sourcesDavid Rodríguez2019-04-246-96/+27
| | |
* | | Merge #7149Bundlerbot2019-05-032-10/+54
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | Properly detect the platform mismatch casefix_bundle_update_crashDavid Rodríguez2019-04-282-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | Remame variable to be more accurateDavid Rodríguez2019-04-281-5/+5
| | | | | | | | | | | | | | | | We're not saving specs here, actually.
| * | | Fix crash when dependency is for another platformDavid Rodríguez2019-04-282-10/+42
| | | |
| * | | Move local variables to where they are usedDavid Rodríguez2019-04-281-6/+8
| | | |
| * | | Add some whitespace for readabilityDavid Rodríguez2019-04-281-0/+2
| | | |
* | | | Merge #7153Bundlerbot2019-05-021-7/+7
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | Rename local variables for readabilityFumiaki MATSUSHIMA2019-05-011-7/+7
| | | | |
* | | | | Merge #7147Bundlerbot2019-05-024-24/+44
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | Fix more specs on an environment with bundler head as a default gemfix_specs_with_bundler_master_installed_globallyDavid Rodríguez2019-04-282-4/+19
| | | | |
| * | | | Unify `bundle show` deprecation specsDavid Rodríguez2019-04-282-20/+24
| | | | |
| * | | | Move skip to the right placeDavid Rodríguez2019-04-281-2/+2
| | | | |
| * | | | Fix license listing for bundler itselfDavid Rodríguez2019-04-282-1/+2
| | | | |
* | | | | Merge #7148Bundlerbot2019-05-013-24/+16
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | Remove now unnecessary methoduse_add_to_load_pathDavid Rodríguez2019-04-281-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | Since we've moved the whole logic to the integration class.
| * | | | | Move common logic to rubygems integrationDavid Rodríguez2019-04-283-19/+16
| | | | | | | | | | | | | | | | | | | | | | | | And use the rubygems method if available.
| * | | | | Remove unnecessary commentDavid Rodríguez2019-04-281-1/+0
| |/ / / /
* | | | | Merge #7151Bundlerbot2019-04-308-32/+25
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
View Lorry Controller Status