summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* And againbump_thor_to_latest_masterDavid Rodríguez2019-11-063-8/+24
|
* And againDavid Rodríguez2019-11-061-2/+2
|
* Bump againDavid Rodríguez2019-11-069-41/+55
|
* Pickup latest changes in thor masterDavid Rodríguez2019-11-0610-164/+32
| | | | | | Using `bin/rake vendor:thor[master]`. So that we're ready for an upcoming release.
* Merge #7424Bundlerbot2019-11-061-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7424: Drop unnecessary `tempfile` require r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The `tempfile` dependency was dropped in [1], but the require was left in there. This could cause gem conflicts because `tempfile` requires `tmpdir` which requires `fileutils`, which loads the default gem instead of our namespaced version, and that could cause fileutils version mismatches and code overriding warnings. [1]: https://github.com/bundler/bundler/commit/4a37d66f3f222739178d798b30fb135f2429fe45 ### What is your fix for the problem, implemented in this PR? My fix is to drop the unnecessary require. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Drop unnecessary `tempfile` requiredrop_unnecessary_tempfile_requireDavid Rodríguez2019-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | The `tempfile` dependency was dropped in [1], but the require was left in there. This could cause gem conflicts because `tempfile` requires `tmpdir` which requires `fileutils`, which loads the default gem instead of our namespaced version, and that could cause fileutils version mismatches and code overriding warnings. [1]: https://github.com/bundler/bundler/commit/4a37d66f3f222739178d798b30fb135f2429fe45
* | Merge #7393Bundlerbot2019-11-062-0/+10
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7393: Make 'bundle add' cache newly added gems when needed r=deivid-rodriguez a=andrehjr ### What was the end-user problem that led to this PR? The problem was that when calling `bundle add` with cache_all as true, I have to call an additional `bundle install` to vendor gems. ### What was your diagnosis of the problem? My diagnosis was that a call to Bundler.load.cache was missing. For example Bundler::CLI::Update does the same after installing gems. ### What is your fix for the problem, implemented in this PR? My fix was to call Bundler.load.cache when `Bundler.app_cache.exist? ` ### Why did you choose this fix out of the possible options? I chose this fix because it looks like this makes the behavior consistent with other commands. I should also say that, as this is my first PR here, I'm not sure that this is the best solution, and it seems an easy fix for #7384. Co-authored-by: André Luis Leal Cardoso Junior <andrehjr@gmail.com>
| * Make bundle add caches newly added gems when needed.André Luis Leal Cardoso Junior2019-11-042-0/+10
| |
* | Merge #7394Bundlerbot2019-11-062-0/+65
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 7394: Add inline RDoc documentation r=hsbt a=zverok Since Bundler became part of the standard library, it renders in Ruby's docs. Unfortunately, what renders there... is not really helpful: https://docs.ruby-lang.org/en/master/Bundler.html I've added rudimentary documentation for `Bundler` module and two of its most user-facing methods to solve this problem at least partially. Co-authored-by: zverok <zverok.offline@gmail.com>
| * | Grammarzverok2019-11-051-1/+1
| | |
| * | Add inline RDoc documentationzverok2019-10-262-0/+65
| |/
* | Merge #7398Bundlerbot2019-11-051-4/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7398: Remove unnecessary lines from `bundler/setup` r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? These lines in the `bundler/setup` file are not necessary. ### What was your diagnosis of the problem? Bundler no longer needs to be in the `$LOAD_PATH` once a version of itself has been loaded. In any case, the `Metadata` source takes care of adding `bundler` to the index: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/source/metadata.rb#L13-L30 and then that spec is added to the resolution here: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/definition.rb#L180-L184 And from the resulting set of specs, the `$LOAD_PATH` is setup: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/runtime.rb#L25-L38 So `bundler` will be present in the `$LOAD_PATH` anyways, and the lines being removed here will never be useful. ### What is your fix for the problem, implemented in this PR? My fix is to remove these lines to make the code easier to follow. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove unnecessary lines from `bundler/setup`remove_unnecessary_load_path_manipulationDavid Rodríguez2019-11-051-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bundler no longer needs to be in the `$LOAD_PATH` once a version of itself has been loaded. In any case, the `Metadata` source takes care of adding `bundler` to the index: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/source/metadata.rb#L13-L30 and then that spec is added to the resolution here: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/definition.rb#L180-L184 And from the resulting set of specs, the `$LOAD_PATH` is setup: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/runtime.rb#L25-L38 So `bundler` will be present in the `$LOAD_PATH` anyways, and the lines being removed here will never be useful.
* | | Merge #7402Bundlerbot2019-11-0558-126/+118
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7402: Spec normalizations r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I saw some room for improvement in our specs and I couldn't help myself :) ### What is your fix for the problem, implemented in this PR? Essentially, the idea of this PR is to avoid using `__FILE__` or other folder-structure specific constructs to look for files, and instead use our helpers ìn `spec/support/path.rb`. The idea is that the helpers in this file are aware that `bundler` specs can be run from ruby-core or the upstream repo, and the folder structure is different for both. Also, the PR normalizes some naming, some duplicated helpers, and the way we require files from specs. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | 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>
View Lorry Controller Status