summaryrefslogtreecommitdiff
path: root/lib/bundler/cli.rb
Commit message (Collapse)AuthorAgeFilesLines
* Merge #5521Bundlerbot2020-01-081-1/+1
|\ | | | | | | | | | | | | | | 5521: bundler gem: Support test-unit as a testing framework r=hsbt a=kou Co-authored-by: Kouhei Sutou <kou@clear-code.com>
| * bundler gem: Support test-unit as a testing frameworkKouhei Sutou2019-12-111-1/+1
| |
* | Use vendorized version of uri libraryDavid Rodríguez2019-12-081-1/+1
|/
* Merge #6455Bundlerbot2019-11-081-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6455: [CLI::Gem] Add a --rubocop option r=deivid-rodriguez a=segiddins Based upon #6451. ### What was the end-user problem that led to this PR? The problem was I always have to remember how to add RuboCop to my Rakefile when I set up a new gem. ### What was your diagnosis of the problem? My diagnosis was that RuboCop has become enough of a community standard that it makes sense to offer it in `bundle gem`. ### What is your fix for the problem, implemented in this PR? My fix adds an option to `bundle gem` to add in RuboCop, in the same way options like `:coc`and `:mit` are handled. ### Why did you choose this fix out of the possible options? I chose this fix because it does not require bundler have an opinion on _how_ rubocop is configured. Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
| * [CLI::Gem] Add a --rubocop optionsegiddins/bundle-gem-rubocop-optionSamuel Giddins2019-10-191-0/+1
| |
* | Merge #7404Bundlerbot2019-11-041-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-011-2/+2
| | | | | | | | | | | | bundler list command
* | | Merge #7401Bundlerbot2019-11-041-3/+0
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Don't silence the UI by defaultDavid Rodríguez2019-10-311-3/+0
| | |
* | | Fix help with command aliasesfix_help_with_command_aliasesDavid Rodríguez2019-10-301-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Normalize "bundle cache" vs "bundle package"normalize_bundle_cacheDavid Rodríguez2019-10-201-11/+9
|/ | | | | | | Use the preferred `bundle cache` everywhere, but leave package as an alias. Remove duplicated tests.
* Fix typoIgor Zubkov2019-10-031-1/+1
|
* Fix typoIgor Zubkov2019-10-031-1/+1
|
* Fix --path option descriptionsDavid Rodríguez2019-08-161-2/+2
| | | | To not mention that the flag is remembered when it's not.
* Deprecate `--path` flag to `bundle check`David Rodríguez2019-08-161-0/+2
|
* Fix remembered flag deprecation messageDavid Rodríguez2019-08-161-1/+1
| | | | It was suggested a deprecated command as a fix.
* Add `--[no-]git` option to `bundle gem`git_option_to_bundle_gemDavid Rodríguez2019-07-311-0/+1
| | | | | I think using `--no-git` can be useful when creating gems inside monorepos.
* Restore `cache_all` flag removalDavid Rodríguez2019-07-241-3/+4
|
* Alias `cache` to `package` nowadd_package_functionality_to_cacheDavid Rodríguez2019-07-151-15/+1
| | | | | | | The additions of the `package` command are not actually backwards incompatible, so we can do this transition without further care. All existing specs of `bundle cache` pass when using the `bundle package` implementation for it.
* Remove `cache_command_is_package` feature flagDavid Rodríguez2019-07-151-3/+3
| | | | | So that we handle the removal of `bundle cache` just like we'll handle the removal of `bundle show` and `bundle console`.
* Always keep `bundle package --all` optionDavid Rodríguez2019-07-151-4/+3
| | | | | | Just change the default. The reason to do this is that the deprecation message talks about the default being changed, not the option being removed.
* Fix incorrect flag usageDavid Rodríguez2019-07-151-1/+1
|
* Remove redundant conditionDavid Rodríguez2019-07-151-4/+2
| | | | This is inside a code branch where the condition is already met.
* Merge #7127Bundlerbot2019-04-231-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7127: Add git and branch options to `bundle add` r=deivid-rodriguez a=tokachev Closes #6841 These changes will allow to add a gem with the git or branch options. ``` bundle add redis --git "https://github.com/redis/redis-rb" --branch "staging" ``` The result in Gemfile will be: ``` gem "redis", "~> 4.0", :git => "https://github.com/redis/redis-rb", :branch => "staging" ``` Co-authored-by: Baumgarten <baumgarten@localhost.localdomain>
| * Add git and branch options to `bundle add`Baumgarten2019-04-131-0/+2
| |
* | Prefer `require_relative` for internal requiresDavid Rodríguez2019-04-191-29/+29
| | | | | | | | | | | | | | | | Due to the way rubygems monkey-patched require interacts with default gems, and given that bundler is a default gem, and that bundler manipulates the LOAD_PATH in very intricated ways, we can reduce the risk of "leaking" to a different copy of `bundler` by using `require_relative` for internal requires.
* | Remove unnecessary requireDavid Rodríguez2019-04-191-1/+0
| |
* | Typo. s/expect/except/David Rodríguez2019-04-051-1/+1
| |
* | Remove `list_command` settingDavid Rodríguez2019-04-051-15/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The list command was still present (just aliased to `bundle show`), even if the setting was set to false. So the setting was at least super confusing if not just wrong. It also led to misleading situations such as ``` $ bundle list --help (...) NAME bundle-list - List all the gems in the bundle SYNOPSIS bundle list [--name-only] [--paths] [--without-group=GROUP] [--only-group=GROUP] (...) $ bundle list --only-group=development Unknown switches '--only-group=development' ``` So, instead, I enable the new list command _always_ and remove the `bundle list => bundle show` alias.
* | Print a better messages on undocumented flagsDavid Rodríguez2019-04-051-8/+12
| | | | | | | | | | Inform about complete removal when `bundle show --outdated` and `bundle show --verbose`.
* | Remove `bundle show` from bundler 3David Rodríguez2019-04-051-27/+28
| |
* | Remove `console_command` settingremove_command_removal_settingsDavid Rodríguez2019-03-311-1/+1
| | | | | | | | | | | | | | | | This setting is not meant to be used by end users. The `console` command is going away and we plan to fully remove the code once we only have to maintain bundler 3 or higher versions. Adding a setting makes it look like the presence of this command is something "configurable", but it's not.
* | Remove `viz_command` settingDavid Rodríguez2019-03-311-1/+1
|/ | | | | | | | This setting is not meant to be used by end users. The `viz` command is going away and we plan to fully remove the code once we only have to maintain bundler 3 or higher versions. Adding a setting makes it look like the presence of this command is something "configurable", but it's not.
* Allow `update` to install when `--no-install` usedno_install_allows_update_to_installDavid Rodríguez2019-03-281-1/+3
| | | | The `--no-install` flag flag is only meant for `bundle package`.
* Move message to present tenseDavid Rodríguez2019-03-171-1/+1
| | | | Because the behavior is still there.
* The cops got meDavid Rodríguez2019-03-121-1/+1
|
* Deprecate a bunch of flags in bundler 2David Rodríguez2019-03-121-17/+34
| | | | | | | Under the previous code, once we stop remembering options, these flags would be automatically removed without deprecation. Instead, first deprecate the options in bundler 2, then remove them and stop remembering them in bundler 3.
* Move `rescue Exception` exceptions inlineDavid Rodríguez2019-03-041-1/+1
|
* Use newest interface to `bundle config` everywhereDavid Rodríguez2019-02-191-4/+4
|
* Enable gemfile flag for bundle lockLaura Paakkinen2018-10-181-0/+2
|
* Refactor initial codecorrect_bundle_show_deprecationDavid Rodríguez2018-10-011-7/+5
|
* Fix `--paths` argument handlingDavid Rodríguez2018-10-011-1/+9
|
* Fix "bundle show" deprecation messagesDavid Rodríguez2018-10-011-1/+9
| | | | | With a single gem, it will be replaced by `bundle info`, not by `bundle list`.
* Make the equivalent change to `bundle update`David Rodríguez2018-09-181-1/+2
|
* Fix issue with initial implementationDavid Rodríguez2018-09-181-1/+1
|
View Lorry Controller Status