summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | Make `bundle clean` clean git extension directoriesDylan Thacker-Smith2019-03-211-1/+1
| | | | |
* | | | | Merge #7052Bundlerbot2019-03-271-2/+36
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7052: Introduce `original_system`, `original_exec`, `unbundled_system`, and `unbundled_exec` r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the `clean_system` and `clean_exec` would print deprecation messages, but there was not alternative for them. ### What was your diagnosis of the problem? My diagnosis was that the helpers are using deprecated behavior and that we should provide non deprecated alternatives. ### What is your fix for the problem, implemented in this PR? My fix is to introduce `original_system`, `original_exec`, `unbundled_system`, and `unbundled_exec` for consistency with the rest of the helpers, and deprecate `clean_system` and `clean_exec`. ### Why did you choose this fix out of the possible options? I chose this fix because while maybe not super pretty names, they offer an alternative consistent with the other helpers. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Introduce `{original,unbundled}_{system,exec}` helpersclean_env_passDavid Rodríguez2019-03-201-2/+36
| |/ / / | | | | | | | | | | | | | | | | Because the previous helpers, `clean_exec` and `clean_system`, use deprecated behavior and thus should be deprecated too.
* | | | Bump thor to 0.20.3tweaking_vendoringDavid Rodríguez2019-03-2510-25/+175
| | | |
* | | | Bump fileutils to 1.1.0David Rodríguez2019-03-251-26/+123
| | | |
* | | | Fix circular require warningsDavid Rodríguez2019-03-233-3/+0
|/ / /
* | | Merge #7045Bundlerbot2019-03-201-2/+14
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7045: Review old `bundle config` interface deprecation r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the `bundle config` command interface changes needed a few tweaks. ### What was your diagnosis of the problem? My diagnosis was that: * `bundle config` deprecation was not getting enabled until bundler 3. * `bundle config` documentation was incorrect about `unset` not supporting `--global` or `--local`. * `bundle config` deprecation didn't give actionable suggestions. ### What is your fix for the problem, implemented in this PR? My fix is to move the version to deprecate the old interface to `bundler 2`, to fix the documentation, and to improve the deprecation messages to give actionable suggestions. ### Why did you choose this fix out of the possible options? I chose this fix because it makes `bundle config` better. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Add actionable suggestions to config deprecationmove_bundle_config_deprecation_to_bundler_2David Rodríguez2019-03-151-1/+13
| | | |
| * | | Fix deprecation version for `bundle config`David Rodríguez2019-03-151-1/+1
| | | | | | | | | | | | | | | | And add specs for it.
* | | | Merge #7047Bundlerbot2019-03-192-21/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7047: Remove remembered options deprecation message r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that this deprecation message is almost always a false positive. I realized about this when being bitten by this deprecation message during on our own specs (see https://travis-ci.org/bundler/bundler/builds/506776354 for example). ### What was your diagnosis of the problem? My diagnosis was that people running things like `bundle install --retry 3` will be annoyed by this deprecation message, because they're not doing anything wrong, really. They have the option to set the flag permanently through configuration, but passing it per command is fine too. The fact that the flag will no longer be remembered is unlikely to cause any problems in my opinion. ### What is your fix for the problem, implemented in this PR? My fix is to remove this message altogether. We already print deprecation messages for the flags that we are removing because they only are guaranteed to work when remembering options (`--with`, `--without`, and friends). For the rest of the flags not being removed from `bundle install`, printing a deprecation message is just annoying since users are not doing anything wrong by using them. ### Why did you choose this fix out of the possible options? I chose this fix because we shouldn't overwhelm users with deprecation messages unless we really need to. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove forgotten options deprecationforgotten_options_deprecation_second_passDavid Rodríguez2019-03-171-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This deprecation will be a false positive in almost every case, so it will be very annoying for users. I realized about this when being bitten by the warning on our own specs on perfectly fine `bundle install` runs (`bundle install --retry 3`). Since we already have the deprecation in place about the options being removed from `bundle install` and being turned into configuration options, I think we can skip this warning altogether since the remaining flags are very unlikely to cause any problems when they start being "forgotten".
| * | | | Move message to present tenseDavid Rodríguez2019-03-171-1/+1
| |/ / / | | | | | | | | | | | | Because the behavior is still there.
* | | | Remove ruby version leftoversremove_ruby_version_leftoversDavid Rodríguez2019-03-153-11/+1
|/ / /
* | | Test and fix `bundle viz` command deprecationDavid Rodríguez2019-03-151-1/+1
|/ /
* | The cops got meDavid Rodríguez2019-03-121-1/+1
| |
* | Deprecate a bunch of flags in bundler 2David Rodríguez2019-03-123-19/+36
| | | | | | | | | | | | | | 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.
* | Allow a scape valve to keep the old behavior for nowDavid Rodríguez2019-03-121-7/+13
| |
* | Teach users how to toggle deprecations offDavid Rodríguez2019-03-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | The deprecations will lead to some "true positives" where users will use `bundle config` and remove the flag, and some "false positives" where users will be fine with the option not being remembered but still want to use the flag on a per command basis. Whatever the case, we need to tell users how to get rid of the warning once they learn and get ready for the new behavior. Otherwise it's going to get super annoying!
* | Don't commit to a deprecation horizonDavid Rodríguez2019-03-121-1/+1
| | | | | | | | | | Bundler 3.0 was incorrect according to the new plan of migrating to https sources first, and then removing custom sources.
* | Get the final spec about DSL sources passingDavid Rodríguez2019-03-121-1/+1
| | | | | | | | | | For now, warn only users that are opting out that the setting will be removed in the future.
* | Delay custom sources deprecation to bundler 3David Rodríguez2019-03-122-3/+3
| | | | | | | | And thus its removal even further.
* | Delay git sources removal to bundler 3 (for now)David Rodríguez2019-03-121-1/+1
| | | | | | | | This allows us to get most of the DSL related deprecation specs passing.
* | github.https setting is booleanDavid Rodríguez2019-03-121-0/+1
| |
* | Remove messy TODO commentsDavid Rodríguez2019-03-121-17/+0
| | | | | | | | | | | | Classic problem: comments do not get as curated as code, so they no longer make sense. I prefer to remove them and try to keep the code self-explaining and in good shape instead.
* | Merge #6999Bundlerbot2019-03-121-4/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6999: Fix multiple gem files deprecation r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was the current message about deprecating `Gemfile` in favor of `gems.rb` was incorrect, and this I'm not sure when it was supposed to be displayed. Its corresponding test was also failing. ### What was your diagnosis of the problem? My diagnosis was that the intention was not to deprecate Gemfile's for the time being, but only warn if the user opts in to `gems.rb` but does not remove the old `Gemfile`. ### What is your fix for the problem, implemented in this PR? My fix is to properly detect the situation where both `Gemfile` and `gems.rb` files are present, and show proper messages guiding the user to properly make the switch. ### Why did you choose this fix out of the possible options? I chose this fix because I think it works and doesn't take this migration too far, since the ecosystem is not yet ready for this at all. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Lighther "prefer gems.rb" deprecationDavid Rodríguez2019-03-011-4/+9
| |/ | | | | | | | | | | | | | | | | The previous logic is unclear to me. It seemed to try to detect only "multiple gemfile situations", but it was doing it incorrectly, I think. The new message is printed _only_ if both gems.rb and Gemfile are detected in the same project. And recommends sticking with gems.rb. But we are not yet deprecating "Gemfile" other than that.
* | Fix rubocop issuesDavid Rodríguez2019-03-081-6/+6
| |
* | Fallback to sequentially fetching specs on 429sDavid Rodríguez2019-03-084-16/+50
| | | | | | | | | | If the compact index returns TooManyRequests, take it easier by requesting dependencies sequentially instead.
* | Fix typoAndrew Nesbitt2019-03-061-1/+1
| |
* | Disable `Style/GuardClause` copfix_offenses_for_more_copsDavid Rodríguez2019-03-041-5/+0
| | | | | | | | | | Sometimes rubocop misunderstand semantics, and forces you to write code that feels worse. I prefer to disable it.
* | Move `rescue Exception` exceptions inlineDavid Rodríguez2019-03-045-5/+5
| |
* | Auto-correct `Style/MutableConstant` rubocop offensesDavid Rodríguez2019-03-045-9/+9
| |
* | Auto-correct `Style/RescueStandardError` offensesDavid Rodríguez2019-03-044-5/+5
| |
* | Auto-correct `Style/Encoding` rubocop issuesDavid Rodríguez2019-03-041-1/+0
| |
* | Auto-correct `Style/StderrPuts` rubocop offensesDavid Rodríguez2019-03-041-1/+1
| |
* | Auto-correct `Style/TrailingCommaInHashLiteral` offensesglobally_enable_some_layout_copsDavid Rodríguez2019-03-043-5/+5
| |
* | Auto-correct `Style/TrailingCommaInArrayLiteral` offensesDavid Rodríguez2019-03-043-3/+3
| |
* | Fully enable some dependent Layout copsDavid Rodríguez2019-03-043-18/+18
| | | | | | | | | | | | These cops leave weird styling if enabled separately, but do what you want if enabled all together. So fix all remaining style issues for them at once.
* | Merge #6978Bundlerbot2019-03-031-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6978: Add check for already installed plugin r=deivid-rodriguez a=ankitkataria ### What was the end-user problem that led to this PR? Fixes #6946 ### What was your diagnosis of the problem? There was no check to ensure that the plugin was already installed or not. ### What is your fix for the problem, implemented in this PR? I added the check [here](https://github.com/bundler/bundler/compare/master...ankitkataria:plugin-fix?expand=1#diff-68bd939cd3589d8fdda08a12433659ebR109) I also added a small test for the same Co-authored-by: Ankit Kataria <ankitkataria28@gmail.com>
| * add check for already installed pluginAnkit Kataria2019-02-211-1/+1
| |
* | Delay `bundle console` removal to bundler 3David Rodríguez2019-02-281-1/+1
| |
* | Delay requiring --all to update everything to bundler 3David Rodríguez2019-02-281-1/+1
| | | | | | | | Since we haven't even yet deprecated the old behavior.
* | Remove rubygems compatibility guardremove_unnecessary_rubygems_filtersDavid Rodríguez2019-02-251-4/+0
| | | | | | | | Bundler 2 can't be installed on these rubygems, so it's not necessary.
* | Remove more unnecessary rubygems version checksDavid Rodríguez2019-02-252-33/+18
| |
* | Remove unnecessary old rubygems deprecationDavid Rodríguez2019-02-251-7/+3
| |
* | Merge #6971Bundlerbot2019-02-241-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6971: Fix warning message about bundler version r=colby-swandale a=deivid-rodriguez Fixes #6909. ### What was the end-user problem that led to this PR? The problem was that we're recommending a command to make a warning go away that doesn't really make the warning go away. ### What was your diagnosis of the problem? My diagnosis was that the current recommendation installs the latest bundler, which might not be the same as the version the lock file was created with. If it's not the same, the warning will not go away. ### What is your fix for the problem, implemented in this PR? My fix is to recommend installing exactly the version the lockfile was created with. ### Why did you choose this fix out of the possible options? I chose this fix because it's really simple and it should work. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Fix warning message about bundler versionfix_upgrade_instructionsDavid Rodríguez2019-02-181-3/+3
| |/ | | | | | | | | | | | | To actually make the warning go away, we need to recommend exactly installing the locked version. Otherwise the latest version gets installed, but not used to being a different major than the one locked, so the warning stays.
* | Remove ruby version major deprecationDavid Rodríguez2019-02-221-3/+0
| | | | | | | | Since the current master will never run those rubies.
* | Rename major_deprecations to silence_deprecationsdeprecation_changesDavid Rodríguez2019-02-212-3/+3
| |
* | Fix deprecations bugDavid Rodríguez2019-02-211-1/+1
| | | | | | | | | | Deprecations enabled or not, we only want to print deprecations for the running major version, never for future versions.
View Lorry Controller Status