summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Always use folder structure aware path helpersspec_normalizationsDavid Rodríguez2019-11-044-6/+8
|
* Simplify a bunch of test requiresDavid Rodríguez2019-11-0443-43/+43
|
* Simplify building some pathsDavid Rodríguez2019-11-043-4/+4
|
* Rename `lib` to `lib_dir`David Rodríguez2019-11-0415-60/+60
| | | | For consistency with `spec_dir`.
* Remove unnecessary local variablesDavid Rodríguez2019-11-041-6/+0
| | | | Call the helper with the same name instead.
* Remove `spec` helper in favor of `spec_dir`David Rodríguez2019-11-044-8/+4
| | | | The `spec` name is too common inside specs for `Gem::Specification`'s.
* Normalize some test requiresDavid Rodríguez2019-11-042-5/+5
|
* Merge #7411Bundlerbot2019-11-042-1/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7411: Try out specs against MRI 2.6 + Rubygems 3.0 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that our Azure build was using outdated versions of ruby and rubygems. ### What was your diagnosis of the problem? My diagnosis was that we should update them. ### What is your fix for the problem, implemented in this PR? My fix is to update them. With the latest versions, failures go down to 319. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Try out specs against MRI 2.6 + Rubygems 3.0windows_refreshDavid Rodríguez2019-11-042-1/+3
| |
* | Merge #7404Bundlerbot2019-11-046-30/+56
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7404: Support multiple groups for --without-group and --only-group options … r=deivid-rodriguez a=fatkodima This is a reworked version of #6939 It accepts multiple groups for `--without-group` and `--only-group`. Closes #6939 Co-authored-by: fatkodima <fatkodima123@gmail.com>
| * | Support multiple groups for --without-group and --only-group options in ↵fatkodima2019-11-016-30/+56
| | | | | | | | | | | | bundler list command
* | | Merge #7399Bundlerbot2019-11-041-1/+1
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7399: Fix some realworld specs testing nothing r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that this helper was printing nothing to the standard output, so the specs in this file were just checking if lockfiles contained the empty string, which is obviously true. For example, https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/spec/realworld/edgecases_spec.rb#L31 ### What was your diagnosis of the problem? My diagnosis was that the helper needs to actually print the extracted information about the resolved gem, so it can be checked that the lockfile is correct. ### What is your fix for the problem, implemented in this PR? My fix adds the missing `puts`. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Fix some realworld specs testing nothingfix_realworld_test_helperDavid Rodríguez2019-10-301-1/+1
| | | | | | | | | | | | | | | | | | This helper was printing nothing to the standard output, so the specs were just checking if lockfiles contained the empty string, which is obviously true.
* | | Merge #7401Bundlerbot2019-11-0418-76/+54
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7401: Stop silencing output by default r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that bundler defaults to a silent UI: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler.rb#L66-L68 In my opinion, this isn't a good behavior for a CLI tool, and forces us to override it in many many different places. It has also caused several issues, for example, https://github.com/bundler/bundler/issues/3710 where `bundle list` was printing nothing. The [solution to that issues](https://github.com/bundler/bundler/pull/3707) led us to add yet more places where we override the default UI, and @indirect [predicting that having to unset the UI everytime we want it to not be silent](https://github.com/bundler/bundler/pull/3707#issuecomment-108646127) would cause many headaches. Well, yeah... I've lost a lot of time trying to figure out why UI was silent sometimes, and normal another times, why some specs printed warnings and some didn't. In particular, see my series of "big fail PRs" fighting against bundler's UI: https://github.com/bundler/bundler/pull/7284, https://github.com/bundler/bundler/pull/7294, https://github.com/bundler/bundler/pull/7305, https://github.com/bundler/bundler/pull/7362. Another series of issues/PRs probably related to this is issue https://github.com/bundler/bundler/issues/6900, where the output would use a different UI on different environments. We had a lot of trouble to reliably fix it (https://github.com/bundler/bundler/pull/6994, https://github.com/bundler/bundler/pull/7002, https://github.com/bundler/bundler/issues/7253). I also run into these issues again when trying out the `RUBYGEMS_GEMDEPS` environment variable that enables `bundler/setup` from rubygems. ### What was your diagnosis of the problem? My diagnosis was that we shouldn't silence UI by default. ### What is your fix for the problem, implemented in this PR? My fix is to, instead of silencing and then overriding the default shell at many places, don't silence it by default and instead make it silent when needed. By doing this, I managed to get 100% of our specs green, so I'm pretty confident that the output is still the same (or if it's not, it's probably because some output/errors where being unintentionally swallowed). Now specs should pass, but they print a bunch of output to the screen. You can see error messages, hard crashes, success messages... Some of them might be showing actual issues with either the code or tests, so I plan to go through each of them and review them. I can do that in this PR or separately, no strong opinion. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Respect log level when showing GemRequireError'sno_silent_output_by_defaultDavid Rodríguez2019-10-312-2/+2
| | |
| * | Revert "Avoid printing deprecation messages during specs"David Rodríguez2019-10-311-15/+9
| | | | | | | | | | | | | | | | | | | | | This reverts commit 0a67ac4dc2bad753e33e11352e97f73c9c1ddeee. And fixes deprecation warnings in another way not that the UI verbosity is predictable.
| * | I don't think we need this nowDavid Rodríguez2019-10-312-4/+3
| | |
| * | More cleanupDavid Rodríguez2019-10-311-7/+0
| | |
| * | Don't silence the UI by defaultDavid Rodríguez2019-10-3113-48/+40
| |/
* | Merge #7410Bundlerbot2019-11-0150-50/+50
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7410: November man pages r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that man pages are outdated after the month change. Well, the problem actually is that I need to fix in a better way (like a monthly scheduled rebuild or something), but I keep just updating the man pages every month... :sweat_smile: ### What is your fix for the problem, implemented in this PR? My fix to run `bin/rake man:build` and commit the result. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | November man pagesnovember_manpagesDavid Rodríguez2019-11-0150-50/+50
|/ /
* | Merge #7376Bundlerbot2019-10-303-0/+36
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7376: bundle info prints gem metadata r=deivid-rodriguez a=orien ### What was the end-user problem that led to this PR? Rubygems has supported [gemspec metadata](https://guides.rubygems.org/specification-reference/#metadata) since version 2.0. I think it'd be great to display this information in response to the `bundle info <gem>` command. ### What is your fix for the problem, implemented in this PR? Added a check for `metadata`, outputting this extra information if it has been included with the gem release. For example: ``` > bundle info rspec-mocks * rspec-mocks (3.8.1) Summary: rspec-mocks-3.8.1 Homepage: https://github.com/rspec/rspec-mocks Documentation: https://rspec.info/documentation/ Source Code: https://github.com/rspec/rspec-mocks Changelog: https://github.com/rspec/rspec-mocks/blob/v3.8.1/Changelog.md Bug Tracker: https://github.com/rspec/rspec-mocks/issues Mailing List: https://groups.google.com/forum/#!forum/rspec Path: /opt/asdf/installs/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/rspec-mocks-3.8.1 ``` For better readability, we could align the values. However, this would mean a change to the existing info property lines (`Summary`, `Homepage`, `Path` and `Default`). Which would potentially break existing scripts that are coupled to the precise output. Co-authored-by: Orien Madgwick <_@orien.io>
| * | Remove respond_to? check for metadata methodOrien Madgwick2019-10-211-1/+1
| | | | | | | | | | | | | | | We can rely on it always being available since in our gemspec we set: required_rubygems_version >= 2.5.2
| * | bundle info prints gem metadataOrien Madgwick2019-10-063-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides more information about the gem to developers. For example: bundle info rspec-mocks * rspec-mocks (3.8.1) Summary: rspec-mocks-3.8.1 Homepage: https://github.com/rspec/rspec-mocks Documentation: https://rspec.info/documentation/ Source Code: https://github.com/rspec/rspec-mocks Changelog: https://github.com/rspec/rspec-mocks/blob/v3.8.1/Changelog.md Bug Tracker: https://github.com/rspec/rspec-mocks/issues Mailing List: https://groups.google.com/forum/#!forum/rspec Path: /opt/asdf/installs/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/rspec-mocks-3.8.1
* | | Merge #7388Bundlerbot2019-10-302-11/+96
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7388: Fix help with command aliases r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the output of `bundle help install` and `bundle install --help` was inconstent with `bundle i --help`, and the same issue with all of the other command aliases. ### What was your diagnosis of the problem? My diagnosis was that the command reformatting so that `bundle <cmd> --help` "redirects" to `bundle help <cmd>` was ignoring command aliases. ### What is your fix for the problem, implemented in this PR? My fix is to make this logic aware of command aliases. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Fix help with command aliasesfix_help_with_command_aliasesDavid Rodríguez2019-10-302-2/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | When using the `-h` flag with command aliases, bundler was showing a default help page instead of our manual, so that for example, `bundle help install` and `bundle install --help` output would be inconstent with `bundle i --help`. This commit fixes that.
| * | Add "ex", and "exe" to "bundle exec" aliasesDavid Rodríguez2019-10-301-2/+3
| | | | | | | | | | | | Since they were already consider aliases for `bundle help`.
| * | Extract aliases to a constant for later reusageDavid Rodríguez2019-10-301-6/+19
| | |
| * | Consistently define aliases after command definitionsDavid Rodríguez2019-10-301-3/+8
| | |
| * | Normalize "list" alias with the rest of alias defsDavid Rodríguez2019-10-301-1/+1
| | | | | | | | | | | | Use a string when defining a single alias.
| * | Reformat constant definitionDavid Rodríguez2019-10-301-3/+1
|/ / | | | | | | To be consistent with the one above it.
* | Merge #7389Bundlerbot2019-10-3019-474/+470
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7389: Wrap up `bundle cache` migration to current `bundle package` r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that after https://github.com/bundler/bundler/pull/7249, we added the current `bundle package` functionality to the current `bundle cache` command, so that these commands are now aliases of each other. The initial plan was to do this in a more careful manner but we concluded that this was only _adding_ functionality to `bundle cache`, so not backwards incompatible. We still need to wrap up the original plan, where `bundle cache` is the preferred command. ### What is your fix for the problem, implemented in this PR? My fix is to migrate docs, tests and help text to use `bundle cache`, and to remove duplicated specs for `bundle cache` and `bundle package`, since they are testing the exact same code. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Normalize "bundle cache" vs "bundle package"normalize_bundle_cacheDavid Rodríguez2019-10-2016-358/+352
| | | | | | | | | | | | | | | | | | | | | Use the preferred `bundle cache` everywhere, but leave package as an alias. Remove duplicated tests.
| * | Remove mentions to bundler history in docsDavid Rodríguez2019-10-203-36/+35
| | | | | | | | | | | | | | | | | | I don't think we need to keep this information in our docs. Users should read docs for the version they're using and the history of bundler distract her from the point of the docs, in my opinion.
| * | Document man:{build,check} tasks when ronn not installedDavid Rodríguez2019-10-201-0/+3
| | |
* | | Merge #7390Bundlerbot2019-10-22707-348/+348
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7390: Bump tested rubies and regenerate cassettes r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we were not testing against the latest patch level rubies. ### What is your fix for the problem, implemented in this PR? My fix is to upgrade our CI config, and regenerate the vcr cassettes, just to keep them up to date. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Bump tested rubies and regenerate cassettesbump_rubiesDavid Rodríguez2019-10-20707-348/+348
| |/ /
* | | Merge #7386Bundlerbot2019-10-221-1/+1
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7386: Suppress `Warning: no department given for MutableConstant` r=colby-swandale a=koic This PR suppresses the following `Warning: no department given for MutableConstant`. ```console % cd path/to/bundler % bundle exec rubocop -v 0.75.1 % bundle exec rubocop --parallel (snip) /Users/koic/src/github.com/bundler/bundler/lib/bundler/gem_helpers.rb: Warning: no department given for MutableConstant. Run `rubocop -a --only Migration/DepartmentName` to fix. ``` Co-authored-by: Koichi ITO <koic.ito@gmail.com>
| * | Suppress `Warning: no department given for MutableConstant`Koichi ITO2019-10-201-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR suppresses the following `Warning: no department given for MutableConstant`. ```console % cd path/to/bundler % bundle exec rubocop -v 0.75.1 % bundle exec rubocop --parallel (snip) /Users/koic/src/github.com/bundler/bundler/lib/bundler/gem_helpers.rb: Warning: no department given for MutableConstant. Run `rubocop -a --only Migration/DepartmentName` to fix. ```
* | Merge #7385Bundlerbot2019-10-205-9/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7385: Remove taint usage on Ruby 2.7+ r=hsbt a=jeremyevans ### What was the end-user problem that led to this PR? Ruby 2.7 is deprecating taint support. See https://bugs.ruby-lang.org/issues/16131 for details. ### What was your diagnosis of the problem? Bundler still uses `untaint` in a few places, which will cause deprecation warnings on Ruby 2.7. ### What is your fix for the problem, implemented in this PR? `s/\.untaint/.tap{|x| x.untaint if RUBY_VERSION < "2.7" }/g` ### Why did you choose this fix out of the possible options? It seemed simplest. Co-authored-by: Jeremy Evans <code@jeremyevans.net>
| * | Only untaint strings on Ruby <2.7Jeremy Evans2019-10-185-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | Ruby 2.7 deprecates taint and it no longer has an effect. This attempts to leave the behavior the same on older Ruby versions, but avoid the use of untaint on Ruby 2.7+. See https://bugs.ruby-lang.org/issues/16131 for details.
* | | Merge #7379Bundlerbot2019-10-191-2/+2
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7379: Switch to double quotes to match rest of file r=deivid-rodriguez a=jonathanhefner ### What was your diagnosis of the problem? It is common to prefer double quotes, unless single quotes are needed. It is also generally preferred to use a consistent quote style (whether double quotes or single quotes). ### What is your fix for the problem, implemented in this PR? Switch the anomalous single quotes to double quotes. Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
| * | Switch to double quotes to match rest of fileJonathan Hefner2019-10-141-2/+2
| | |
* | | Merge #4474Bundlerbot2019-10-144-131/+292
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4474: Improve readability of outdated r=deivid-rodriguez a=tlynam Haven't fixed tests since wanted buy-in. Before: ``` Outdated gems included in the bundle: * active_model_serializers (newest 0.9.5, installed 0.8.3, requested ~> 0.8.0) in group "default" * activerecord-import (newest 0.13.0, installed 0.10.0) in group "default" * addressable (newest 2.4.0, installed 2.3.5, requested = 2.3.5) in group "default" * airbrake (newest 5.2.3, installed 5.1.0) in group "default" * bootstrap-sass (newest 3.3.6, installed 3.3.5.1) in group "default" * capistrano (newest 3.5.0, installed 3.4.0, requested ~> 3.4) in group "development" * capistrano-rails (newest 1.1.6, installed 1.1.3, requested ~> 1.1.1) in group "development" ``` After: ``` --pretty Outdated gems included in the bundle: Gem Name New Installed Requested Groups airbrake 5.3.0 5.0.3 default better_errors 2.1.1 1.0.1 ~> 1.0.1 development bootstrap-sass 3.3.6 3.3.0.1 ~> 3.3.0.1 default factory_girl_rails 4.7.0 4.4.1 test, development --pretty --verbose Outdated gems included in the bundle: Gem Name New Installed Requested Groups Load Path airbrake 5.3.0 5.0.3 default /Users/todd/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/specifications/airbrake-5.3.0.gemspec better_errors 2.1.1 1.0.1 ~> 1.0.1 development /Users/todd/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/specifications/better_errors-2.1.1.gemspec bootstrap-sass 3.3.6 3.3.0.1 ~> 3.3.0.1 default /Users/todd/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/specifications/bootstrap-sass-3.3.6.gemspec factory_girl 4.7.0 4.4.0 /Users/todd/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/specifications/factory_girl-4.7.0.gemspec factory_girl_rails 4.7.0 4.4.1 test, development /Users/todd/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/specifications/factory_girl_rails-4.7.0.gemspec ``` Co-authored-by: Todd Lynam <tlynam@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Rename "Locked" to "Current"David Rodríguez2019-10-123-54/+54
| | |
| * | Split --verbose option to a separate specDavid Rodríguez2019-10-121-2/+35
| | |
| * | Normalize `bundle outdated --verbose` option handlingDavid Rodríguez2019-10-121-2/+2
| | | | | | | | | | | | | | | `--parseable` checks `Bundler.ui.debug?` instead of look at the option directly.
| * | Inline one methodDavid Rodríguez2019-10-121-7/+3
| | | | | | | | | | | | | | | All the other screen output and checks for `--parseable` are doing inline, so let's do it here too.
| * | Don't include table header when orderingDavid Rodríguez2019-10-122-4/+27
| | |
| * | Remove --pretty option and make it the defaultDavid Rodríguez2019-10-124-109/+193
| | |
View Lorry Controller Status