summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Fully switch to https sourceshttps_sourcesDavid Rodríguez2019-04-246-96/+27
|
* Merge #6329Bundlerbot2019-04-242-6/+50
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6329: Stop printing “failed to update” message when changing sources r=segiddins a=segiddins ### What was the end-user problem that led to this PR? The problem was `bundle update` shows incorrect message when updating git gems Closes #6325 ### What was your diagnosis of the problem? My diagnosis was we need to check if the source has changed ### What is your fix for the problem, implemented in this PR? My fix only prints the message when the source has not changed Note that is does not yet fix the "updated the git sha" case, since the locked spec and the new spec actually share the same source object! Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Grab previous sources early enough (before they change)seg-no-warning-when-updating-sha-not-versionDavid Rodríguez2019-04-131-4/+12
| | | | | | | | | | And make sure the revision is actually fetched, by saving to "to_s" version, that includes it.
| * Remove unneeded checkDavid Rodríguez2019-04-131-1/+1
| | | | | | | | If it's not needed for version, it shouldn't be needed for source.
| * Early return earlier to further simplifyDavid Rodríguez2019-04-131-2/+2
| |
| * Rename variables to make code more clearDavid Rodríguez2019-04-131-6/+6
| |
| * Add a failing spec for not warning when a git gem updates ref but not versionSamuel Giddins2019-04-131-0/+16
| |
| * [Update] Stop printing “failed to update” message when changing sourcesSamuel Giddins2019-04-132-0/+20
| |
* | Merge #7129Bundlerbot2019-04-242-2/+52
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7129: Bundle env improvements r=deivid-rodriguez a=deivid-rodriguez This came from debugging #7096. ### What was the end-user problem that led to this PR? The problem was that `bundle env` is great, but could be more useful and accurate. ### What is your fix for the problem, implemented in this PR? My fix is to start improving it, by dumping more paths, and more accurate information, and getting the paths tested. ### Why did you choose this fix out of the possible options? I have a few more improvements in mind, but I want to keep my PRs small. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove unnecessary env variable checkingbundle_env_improvementsDavid Rodríguez2019-04-151-2/+2
| | | | | | | | | | | | | | | | | | Rubygems already sets these paths from the environment, and once they are set, it uses the paths and not the environment. So the check is unnecessary and potentially misleading.
| * | Add user home to `bundle env`David Rodríguez2019-04-152-0/+8
| | |
| * | Add some specs for rubygems paths in `bundle env`David Rodríguez2019-04-151-0/+41
| | |
| * | Add require so that env specs can run in isolationDavid Rodríguez2019-04-151-0/+1
| | |
* | | Merge #7124Bundlerbot2019-04-242-1/+14
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7124: Skip platform warnings in inline mode r=indirect a=deivid-rodriguez Fixes #6822. ### What was the end-user problem that led to this PR? The problem was that inline mode prints platform warnings recommending to run `bundle lock` commands. ### What was your diagnosis of the problem? My diagnosis was that the platform is always missing in the lock file since there's no lock file here. ### What is your fix for the problem, implemented in this PR? My fix is to skip platform warnings in this case. ### Why did you choose this fix out of the possible options? I chose this fix because it's simple. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Skip platform warnings in inline modeskip_platform_warnings_during_bundle_inlineDavid Rodríguez2019-04-242-1/+14
|/ / / | | | | | | | | | Since there's no lock file, I don't think they make sense.
* | | Merge #7125Bundlerbot2019-04-242-15/+31
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7125: Ignore `frozen` setting in inline mode r=indirect a=deivid-rodriguez Fixes #7114. ### What was the end-user problem that led to this PR? The problem was that the inline mode wouldn't work if `BUNDLE_FROZEN` is set. ### What was your diagnosis of the problem? My diagnosis was that since we're in frozen mode, the current platform doesn't get added to the definition, and thus platform validation fails. ### What is your fix for the problem, implemented in this PR? My fix is to temporary ignore `BUNDLE_FROZEN` for the inline mode. The inline mode can't really be frozen since it has no lock file. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Ignore `frozen` setting in inline modeignore_frozen_setting_in_inline_modeDavid Rodríguez2019-04-122-15/+31
| | | |
* | | | Merge #7127Bundlerbot2019-04-235-3/+39
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-135-3/+39
| | | | |
* | | | | Merge #7136Bundlerbot2019-04-231-4/+4
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7136: Bump CI rubies to latest patch levels r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that new rubies have been released, and we're not yet testing against them, ### What is your fix for the problem, implemented in this PR? My fix is to update our CI matrix. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | | Bump CI rubies to latest patch levelsDavid Rodríguez2019-04-231-4/+4
|/ / / / /
* | | | | Merge #7100Bundlerbot2019-04-2350-131/+138
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7100: Prefer `require_relative` for internal requires r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundler` seems to, in some very rare cases, leak to the copy of itself installed as a default gem. I have been able to reproduce this only for stuff that we have already fixed. For example: https://github.com/bundler/bundler/pull/6502. However, I have the gut feeling that this can still happen under some conditions, because sometimes we still get reports from people using bundler 2, and getting the error "You must user Bundler 2 or greater with this Gemfile". ### What was your diagnosis of the problem? My diagnosis was that somehow, due to the complicated LOAD_PATH manipulation bundler does, we may endup requiring bundler files in another copy of bundler. ### What is your fix for the problem, implemented in this PR? My fix is not really a fix, although it _might_ prevent the potential issue from happening. As @colby-swandale would say, we should fix the real culprit instead. However, I think using `require_relative` is a better practice anyways, because it makes it clear that you are requiring "internal" files and not files from some dependencies. And it should also be faster because it does not search the LOAD_PATH. And it skips the rubygems monkeypatches to `require`, which seems also good. ### Why did you choose this fix out of the possible options? I chose this fix because I think it's a good practice. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | | Add spec for using relative requiresrequire_relativeDavid Rodríguez2019-04-222-1/+17
| | | | | |
| * | | | | Add missing requireDavid Rodríguez2019-04-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | So that the spec can be run in isolation.
| * | | | | One moreDavid Rodríguez2019-04-191-1/+1
| | | | | |
| * | | | | Remove dummy commentDavid Rodríguez2019-04-191-2/+0
| | | | | |
| * | | | | Load executable relatively in the first placeDavid Rodríguez2019-04-191-12/+4
| | | | | |
| * | | | | Prefer `require_relative` for internal requiresDavid Rodríguez2019-04-1949-114/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | |_|/ / | |/| | |
* | | | | Merge #7115Bundlerbot2019-04-232-51/+52
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7115: Allow local install on jruby r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bin/rake install:local` fails on jruby. ### What was your diagnosis of the problem? My diagnosis was that the `ronn` gem does not support `jruby`. Since the `install:local` task builds docs on the fly, the task crashes. ### What is your fix for the problem, implemented in this PR? My fix is to make the `man:build` task a noop on jruby, so that `bin/rake install:local` can be run on jruby, so jruby users can easily try out bundler's master. ### Why did you choose this fix out of the possible options? I chose this fix because it sounds like a good workaround. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | | Mock `man:build` task on jrubyallow_local_install_on_jrubyDavid Rodríguez2019-04-121-47/+51
| | | | | | | | | | | | | | | | | | | | | | | | So that `rake install:local` at least works.
| * | | | | Remove `man:require` taskDavid Rodríguez2019-04-122-4/+1
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | The ronn gem is needed for building man pages, that's already guarded. The `release` task is irrelevant.
* | | | | Merge #7122Bundlerbot2019-04-231-3/+1
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7122: Remove standard output from `with_rubygems` r=deivid-rodriguez a=deivid-rodriguez This PR might be very specific to my setup, but it would certainly help me. ### What was the end-user problem that led to this PR? The problem was that sometimes I don't find out early about rubocop issues, so I have to push extra commits to fix them, and that means time and CI resources. ### What was your diagnosis of the problem? My diagnosis was that: * I run rubocop automatically on save from `vim using [ale](https://github.com/w0rp/ale). * I set `ENV["RGV"] = master`, so that I always run the latest rubygems. Because of setting `ENV["RGV"]`, the `with_rubygems` script is run everytime a binstub is loaded (including `rubocop`). This script prints some git information to the standard output. Since ALE expects a very specific output from `rubocop`, the fact that the `with_rubygems` script prints stuff to the standard output means that ALE no longer works, and I don't get to early fix style issues. ### What is your fix for the problem, implemented in this PR? My fix is to make the `with_rubygems` script be silent. ### Why did you choose this fix out of the possible options? I could've removed loading the `with_rubygems` script from the `rubocop` binstub, but I chose this fix because other subcommands in the script already seemed to try to be silent, like the `--quiet` flag passed to `git checkout`. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove standard output from `with_rubygems`remove_output_from_with_rubygemsDavid Rodríguez2019-04-121-3/+1
| |/ / /
* | | | Merge #7120Bundlerbot2019-04-141-6/+27
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7120: Fix spec calling incorrect helper r=deivid-rodriguez a=deivid-rodriguez Thanks so much for the contribution! To make reviewing this PR a bit easier, please fill out answers to the following questions. ### What was the end-user problem that led to this PR? The problem was the subprocess spawed by one spec was crashing, but that was not making the spec fail. ### What was your diagnosis of the problem? My diagnosis was that since the spec was checking for a failure status of the subprocess, that was not specific enough to detect the particular bug in this spec (it was calling `clean_system`, removed from bundler 3, instead of `unbundled_system`). ### What is your fix for the problem, implemented in this PR? My fix is to restore the previous strategy for these specs, namely, check for a more specific status than 0 or 1. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Fix spec calling incorrect helperfix_helpers_specsDavid Rodríguez2019-04-121-6/+27
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spec was crashing on bundler 3, but since the spec was checking for a failure status for the subprocess, it was actually passing. So, as part of this change, I make helper specs more resilient again. These specs were previously checking for a more specific status than 0 or 1, but I removed that at some point. Now I see how it was useful, so I'm restoring it.
* | | | Merge #7043Bundlerbot2019-04-142-349/+117
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7043: Remove old rubygems compatibility code r=bronzdoc a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I was unsure where I needed to add the compatibility layer to #6963, and it took me a bit to scan through the compatibility file and figure it out. ### What was your diagnosis of the problem? My diagnosis was that all this compatibility code is unused but makes this file harder to understand and scan through. ### What is your fix for the problem, implemented in this PR? My fix is to remove the code. ### Why did you choose this fix out of the possible options? I chose this fix because we can do it, I think. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove more unnecessary coderemove_old_rubygems_compatibility_codeDavid Rodríguez2019-04-091-2/+0
| | | | | | | | | | | | | | | | | | | | The `full_gem_path` writer has been there since rubygems 2.2
| * | | | Remove unnecessary codeDavid Rodríguez2019-04-091-10/+4
| | | | | | | | | | | | | | | | | | | | The `source` method has been there since rubygems 2.1.
| * | | | Remove unused variableDavid Rodríguez2019-04-091-2/+0
| | | | |
| * | | | Remove more unnecessary logicDavid Rodríguez2019-04-091-8/+3
| | | | |
| * | | | Remove last level of inheritanceDavid Rodríguez2019-04-091-127/+120
| | | | |
| * | | | Remove one level of inheritanceDavid Rodríguez2019-04-091-5/+2
| | | | |
| * | | | Remove more uneeded stuffDavid Rodríguez2019-04-091-62/+0
| | | | |
| * | | | Remove old rubygems compatibility codeDavid Rodríguez2019-04-091-146/+1
| | | | |
* | | | | Merge #7128Bundlerbot2019-04-1413-14/+15
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7128: Backport to workaround from ruby core. r=deivid-rodriguez a=hsbt ### What was the end-user problem that led to this PR? The current master branch couldn't invoke with the ruby core repository. ### What was your diagnosis of the problem? 1. We need to add explicitly declare `rspec` in spec_helper.rb 2. Some examples were failed on ruby core repository. ### What is your fix for the problem, implemented in this PR? 1. simply added. 2. update the `ruby_repo` labels for skipping to run. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | | | | Update ruby_repo filter with the latest ruby-core implementaion.SHIBATA Hiroshi2019-04-1412-14/+14
| | | | | |
| * | | | | Added explicitly loading rspec. Because ruby core didn't use rspec cli directly.SHIBATA Hiroshi2019-04-141-0/+1
| | |_|_|/ | |/| | |
* | | | | Merge #6730Bundlerbot2019-04-1445-202/+174
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6730: Print errors to stderr by default, and remove configuration option r=greysteil a=greysteil ### What was the end-user problem that led to this PR? The problem was #6729 - Bundler unexpectedly outputs error and warning messages to STDOUT. ### What was your diagnosis of the problem? My diagnosis was that whilst very minorly breaking, this is essentially a bug fix, and should be considered for inclusion for Bundler 2.0 even if very few other breaking changes are. ### What is your fix for the problem, implemented in this PR? My fix was so switch output for warning and error messages to STDERR, and remove the configuration option (as is redundant once the setup is flipped - anyone wanting to redirect those message to STDOUT could do so in their shell). ### Why did you choose this fix out of the possible options? I chose this fix because I think the new behaviour is what everyone would expect, and we should get it out from behind its feature switch sooner rather than later. Alternatively, we might want to keep the Bundler 2.0 release "purer" by only dropping Ruby versions in it - that's totally fine too, but I figured we should have the code to discus #6729, rather than doing it in abstract. Co-authored-by: Grey Baker <greysteil@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | s/last_command.stdout/out/greysteil/print-errors-to-stderrDavid Rodríguez2019-04-1215-44/+44
| | | | |
View Lorry Controller Status