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>
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>
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>
Since there's no lock file, I don't think they make sense.
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>
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>
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>
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>