summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | Opt in to the new public method if availablebundle_exec_irbDavid Rodríguez2019-03-271-1/+11
| | | | |
| * | | | Allow to `bundle exec` default gemsDavid Rodríguez2019-03-271-0/+9
| | | | | | | | | | | | | | | | | | | | Even when they are not explicitly specified in the Gemfile.
* | | | | Merge #7026Bundlerbot2019-03-312-9/+17
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7026: Add missing `bundle info` feature, bug fix, and specs r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundler info GEM` did not have feature parity with `bundle show GEM`, and it should because it's the recommended alternative. Also, `bundle info bundler` was showing an incorrect path while `bundle show bundler` was correct. ### What was your diagnosis of the problem? My diagnosis was that some code should be pulled from `bundle show`. ### What is your fix for the problem, implemented in this PR? My fix is to port the missing feature, bug fix, and specs to `bundle info` from `bundle show`. ### Why did you choose this fix out of the possible options? I chose this fix because it guarantees that the recommended alternative will work similarly to the current show command. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | | Don't raise if users choose to exitnew_info_specsDavid Rodríguez2019-03-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | Just exit.
| * | | | | Remove incorrect `raise`David Rodríguez2019-03-141-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The raise is using the name of the class on its message! ``` Could not find gem 'Bundler::CLI::Common'. ``` Since we've never received a WTF report about this, I'll assume this is just dead code and remove it.
| * | | | | Port regexp feature from `bundle show`David Rodríguez2019-03-141-1/+1
| | | | | |
| * | | | | Fix `bundle info bundler` pathDavid Rodríguez2019-03-141-1/+7
| | | | | |
| * | | | | Make `bundle info rails` create a lock fileDavid Rodríguez2019-03-141-0/+5
| | |_|_|/ | |/| | | | | | | | | | | | | Just like `bundle show rails` did.
* | | | | Merge #7078Bundlerbot2019-03-291-1/+3
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7078: Allow `update` to install when `--no-install` used r=colby-swandale a=deivid-rodriguez Fixes #7077. ### What was the end-user problem that led to this PR? The problem was #7077. When the `no_install` configuration is activated, this prevents `bundle update` from installing gems, but `no_install` is only meant to affect `bundle package`. ### What was your diagnosis of the problem? My diagnosis was that `bundle update` needs to ignore this setting. ### What is your fix for the problem, implemented in this PR? My fix is to the same `bundle install` does to fix this problem. ### Why did you choose this fix out of the possible options? I chose this fix because it's the most straightforward solution, although the handling of this flag could probably use some refactoring. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | | 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`.
* | | | | Merge #7035Bundlerbot2019-03-286-138/+2
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7035: Unify the certificates for rubygems.org to rubygems store. r=deivid-rodriguez a=hsbt ### What was the end-user problem that led to this PR? The problem was the users have duplicated certificates in their boxes. ### What was your diagnosis of the problem? I wonder why bundler has a certificates copy from rubygems. It raised up in the tracker of ruby core. https://bugs.ruby-lang.org/issues/15384 ### What is your fix for the problem, implemented in this PR? I removed the duplicated certificates from bundler, and fallback to rubygems's one. ### Why did you choose this fix out of the possible options? Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | | | Use Gem::Request.get_cert_files instead of hard-coded paths.unify-certificationSHIBATA Hiroshi2019-03-181-2/+2
| | | | |
| * | | | Use Gem::RUBYGEMS_DIR instead of RbConfig::CONFIGSHIBATA Hiroshi2019-03-141-8/+1
| | | | |
| * | | | rubocop -aSHIBATA Hiroshi2019-03-141-1/+1
| | | | |
| * | | | Unify the certificates for rubygems.org to rubygems store.SHIBATA Hiroshi2019-03-146-137/+8
| |/ / / | | | | | | | | | | | | | | | | * Removed CertificateManager and related rake tasks. * Removed the certificates from bundler internal.
* | | | Bump vendored fileutils to 1.2.0vendor_last_fileutilsDavid Rodríguez2019-03-272-24/+38
| |/ / |/| |
* | | Merge #7036Bundlerbot2019-03-272-6/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7036: Bump travis rubies r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that hacks create confusion, even if they include TODO notes. ### What was your diagnosis of the problem? My diagnosis was that we can should upgrade to the latest ruby releases to reduce the number of hacks we need to maintain. ### What is your fix for the problem, implemented in this PR? My fix is to upgrade rubies and remove hacks. ### Why did you choose this fix out of the possible options? I chose this fix because it's a good change. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Lazily require rubygems config filebump_travis_rubiesDavid Rodríguez2019-03-261-1/+0
| | | | | | | | | | | | | | | | To avoid activation of the `etc` gem.
| * | | Patch vendored fileutils to not activate `etc` gemDavid Rodríguez2019-03-261-5/+2
| | | |
* | | | Merge #7059Bundlerbot2019-03-271-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7059: Make `bundle clean` clean git extension directories r=hsbt a=dylanahsmith Fixes #7058 This PR fixes it by adding the native extension directories for git gems to the ones for non-git gems. This is used to get the unused extension directories (`stale_extension_dirs = extension_dirs - spec_extension_paths`) which was already excluding extension directories for git gems. Co-authored-by: Dylan Thacker-Smith <dylan.smith@shopify.com>
| * | | | 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.
View Lorry Controller Status