summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 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 #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>
| * | | | | Bump rubocop to 0.68.0rubocop_0_68David Rodríguez2019-04-308-32/+25
| | | | | |
* | | | | | Merge #7150Bundlerbot2019-04-304-9/+10
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | Fix message about skipped groups for `bundle update`proper_group_skip_message_for_bundle_updateDavid Rodríguez2019-04-284-9/+10
| | | | | | |
| * | | | | | Move spec to a better locationDavid Rodríguez2019-04-281-0/+0
| | |_|/ / / | |/| | | | | | | | | | | | | | | | Since it includes stuff for `bundle update` too.
* | | | | | Merge #7138Bundlerbot2019-04-2910-29/+15
|\ \ \ \ \ \ | |_|/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | Remove unnecessary BUNDLER_SPEC_RUNremove_bundler_spec_runDavid Rodríguez2019-04-2310-29/+15
| | | | | |
* | | | | | Merge #7140Bundlerbot2019-04-292-6/+12
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
View Lorry Controller Status