summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Version 2.1.2David Rodríguez2019-12-191-1/+1
|
* Merge #7505Bundlerbot2019-12-191-0/+2
| | | | | | | | | | | | | | | | | | | | | 7505: Make sure to `require "rubygems"` explicitly r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was some setups have `--disable=gem` in `RUBYOPT`, and sometimes use `bundler` without modifying that env. ### What was your diagnosis of the problem? My diagnosis was that we shouldn't break those setups just to save a `require`. ### What is your fix for the problem, implemented in this PR? My fix is to add a `require "rubygems"` on top of the file that needs it. Fixes #7487. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit eada59b3d37d6f2f1a05b2d8052a499dfb8fd222)
* Version 2.1.1David Rodríguez2019-12-171-1/+1
|
* Merge #7498Bundlerbot2019-12-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 7498: Add compatibility methods for `rubygems-bundler` gem r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundler install` on a `ruby` installation using `rvm` is broken by default. ### What was your diagnosis of the problem? My diagnosis was that during 2.1.0 development phase I removed some stuff I thought it was internal and nobody would be using. ### What is your fix for the problem, implemented in this PR? My fix is to restore a minimal compatibility layer so that this stuff works again. ### Why did you choose this fix out of the possible options? I chose this fix because I think this is the minimum set of additions that gets stuff working again. Fixes #7488. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit f3f34bc5e62c513190f7608edab5818414ee9669)
* Merge #7493Bundlerbot2019-12-172-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 7493: Fix another silent rubygems issue r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we still have some issues where using the `gem` script on a `bundler` context is silenced. ### What was your diagnosis of the problem? My diagnosis was that `bundle exec` adds `-rbundler/setup` to RUBYOPT which silences `rubygems` output, and that we need to reset `rubygems` UI after that so that if we end up shelling out to `gem`, it is not silent. The previous approach worked for loading the `gem` script in-process, but didn't work in other case. ### What is your fix for the problem, implemented in this PR? My fix is to reset rubygems UI right after `bundler/setup`. ### Why did you choose this fix out of the possible options? I chose this fix because it fixes the problem independently of the rubygems version being run, but we can probably also fix this more cleanly inside the `gem` script by adding something like `Gem::DefaultUserInteraction.ui = Gem::ConsoleUI.new` at the top of the script. Fixes #7490. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit f54ae4f4b2e287792f53410dec42e6b26b3dfcaa)
* Version 2.1.0David Rodríguez2019-12-151-1/+1
|
* Merge #7480Bundlerbot2019-12-153-9/+44
| | | | | | | | | | | | | | | 7480: Vendor thor 1.0.0 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `thor` 1.0.0 has been released, so we should vendor it. ### What is your fix for the problem, implemented in this PR? My fix is to vendor it. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 935c7272ba0f17f81823e704b54627b75cf7f913)
* Merge #7418Bundlerbot2019-12-131-31/+36
| | | | | | | | | | | 7418: Restore previous BUNDLE_GEMFILE in bundler/inline r=deivid-rodriguez a=fatkodima [Without spacing changes](https://github.com/bundler/bundler/pull/7418/files?w=1) Closes #7159 Co-authored-by: fatkodima <fatkodima123@gmail.com> (cherry picked from commit 4367f9ada53f72537309987772f48d357bbd5e72)
* Merge #7475Bundlerbot2019-12-133-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 7475: Delay deprecation of `bundle config` and `bundle update` without args r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem I was thinking about the upcoming release of bundler 2.1.0, and I'm not convinced about these two deprecations. I'm not necessarily against them, but these command are very common IMO, and we'll be making them harder to run. Again, maybe for good reasons, but still. That will be combined with the fact that: * In this same release, we'll be enabling all of the other deprecations. * Ruby 2.7 will include bundler 2.1 and ruby 2.7 will also come with a lot of warnings about keyword arguments. ### What was your diagnosis of the problem? My diagnosis was that I think it's better to postpone these two deprecations for now. Get the other deprecations going and get user feedback about them, and then worry about these two later. ### What is your fix for the problem, implemented in this PR? My fix is to delay both deprecations. ### Why did you choose this fix out of the possible options? I chose this fix because I don't want to be too annoying to users at this moment. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 69a88cf6e8bb2aeebd2b378fc9719eec2f3a7fef)
* Merge #7460Bundlerbot2019-12-1329-55/+4201
| | | | | | | | | | | | | | | | | | | 7460: Vendor `uri` library r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that after the gemification of the `uri` library (which will happen in ruby 2.7), `bundler` will activate the default version of the new library inside its own `bundler/setup` code. That means users won't be able to specify the version of the library they want/need to use in their own Gemfiles. ### What was your diagnosis of the problem? My diagnosis was that we should avoid using `uri` inside `bundler/setup` code. ### What is your fix for the problem, implemented in this PR? My fix is to vendor the `uri` library, like we did with `fileutils`. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 6394536271a0326efd4ed3544b78e528da7e90b1)
* Merge #7474Bundlerbot2019-12-131-10/+12
| | | | | | | | | | | | | | | | | | | | | 7474: Fix `bundle exec rake install` failing r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I noticed `bundle exec rake install` was failing on my gem using the latest prerelease of bundler. ### What was your diagnosis of the problem? My diagnosis was that `bundler` silences output of rubygems by default, and in a `bundle exec` context, `bundler/setup` is always required by subprocesses. So, the `rake install` task is silencing rubygems, but it requires it to not be silent: https://github.com/bundler/bundler/blob/bada03dd6d4d15828fb5b2cf7f744948e88a69a3/lib/bundler/gem_helper.rb#L91-L92 ### What is your fix for the problem, implemented in this PR? My fix is to wrap the execution of the rubygems subprocess with `Bundler.with_original_env` so that the `gem` command runs without `bundler` involved. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit f44ebf017001239a3e66589dff5aa77f631ca6e2)
* Merge #7473Bundlerbot2019-12-133-57/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 7473: Cleanup some unnecessary code r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was #7460 is very big so I want to extract these changes to a separate PR, so that we're more aware of them. ### What was your diagnosis of the problem? My diagnosis was that this code can be removed. In particular, in the `GemRemoteFetcher` class there was the following comment https://github.com/bundler/bundler/blob/25595896eb0f8dfd004d941093bf1d8f4a39aeeb/lib/bundler/gem_remote_fetcher.rb#L9-L10 After having a look, I think the comment would make sense if where it says "gemstash", it actually meant "bundler". That would make sense to me since this is about fetching remote specs, so I would assume it's the client side running it. Assuming this is the correct interpretation, we can remove the code since our minimum supported rubygems version is 2.5.2, and this code was included in rubygems in 2.5.0. ### What is your fix for the problem, implemented in this PR? My fix is to remove the `GemRemoteFetcher` class, plus simplify other related code. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit bada03dd6d4d15828fb5b2cf7f744948e88a69a3)
* Merge #7471Bundlerbot2019-12-1310-45/+83
| | | | | | | | | | | | | | | | | 7471: Vendor latest thor's master r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I need to pull some changes from latest `thor` master to avoid loading the `uri` library for #7460. ### What is your fix for the problem, implemented in this PR? My fix is to run `bin/rake vendor:thor[master]` and commit changes. Not that I used an `automatiek` version including https://github.com/segiddins/automatiek/pull/7 that avoids some false positive when replacing namespaces. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 25595896eb0f8dfd004d941093bf1d8f4a39aeeb)
* Merge #7463Bundlerbot2019-12-132-8/+3
| | | | | | | | | | | | | | | 7463: Vendor fileutils 1.4.1 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was no big deal. Just a discrepancy between the fileutils version we're vendoring and the one that will ship with ruby 2.7. This doesn't cause any issues, but I prefer that they match. ### What is your fix for the problem, implemented in this PR? My fix is to `bin/rake vendor:fileutils[v1.4.1]` and commit the result. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit f6b970d0b8347681fdcf804a837876798a9230ef)
* Merge #7456Bundlerbot2019-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | 7456: Lazily load CGI 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 that our ruby-head build is failing in CI. ### What was your diagnosis of the problem? My diagnosis was that since `cgi` is now a default gem on ruby 2.7, we're getting someunintended activations of the new default gem inside our specs. ### What is your fix for the problem, implemented in this PR? My fix is to lazily load CGI. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit c3eae8ea436af06ab2c3f4bdd25bd9dd6e7c9eef)
* Merge #7455Bundlerbot2019-12-131-1/+2
| | | | | | | | | | | | | | | | | | | | | 7455: Lazily load `open3` r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was `open3` will be gemified in ruby 2.7, and since we use it inside `bundler`, we might activate a version causing a conflict with the user's choice. ### What was your diagnosis of the problem? My diagnosis was that only loading it when needed should be better. ### What is your fix for the problem, implemented in this PR? My fix is to lazily load it. I expect this PR to fix [some of the errors](https://travis-ci.org/bundler/bundler/jobs/615940817) currently happening in our CI against ruby-head. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 2a5378c8c50773b6f8974eb4914894c7c5bd766b)
* Merge #7419Bundlerbot2019-12-131-3/+4
| | | | | | | | | 7419: Add :glob to git source uniqueness r=deivid-rodriguez a=fatkodima Closes #7346 Co-authored-by: fatkodima <fatkodima123@gmail.com> (cherry picked from commit 87449d535a731b818411523e34468f1f548adca9)
* Merge #7442Bundlerbot2019-12-131-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7442: Fix `bundle exec`'ing to rubygems being silent r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that #7401 caused a regression where `bundle exec`'ing to rubygems would silence rubygems output. ### What was your diagnosis of the problem? My diagnosis was that the removal of: * Code where `Bundler::RGProxy` would be only set conditionally on `Bundler.ui =` not being passed `nil`. * Code setting `Bundler.ui` to `nil` right before shelling during `bundle exec`. caused rubygems UI to be silent during `bundle exec gem`. ### What is your fix for the problem, implemented in this PR? My fix is to explictly "unsilence" rubygems UI before `bundle exec` calls. ### Why did you choose this fix out of the possible options? I chose this fix because it's more explicit than the previous one. Fixes #7441. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit a11c104c5b6222c018248b585cca2a4f340a9a71)
* Merge #7266Bundlerbot2019-11-1218-217/+118
| | | | | | | | | | | | | | | | | | | | | | | 7266: Bump to thor's master r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem is that we are currently cherry-picking some `thor` changes that are currently living on its master branch, but have not been released yet. The changes are about using `require_relative`and not relying on the LOAD_PATH. I cherry-picked them, because they were needed to fix some issues with `bundler` installed as a default gem. Anyways, it's always better to depend on released versions of our dependencies. ### What was your diagnosis of the problem? My diagnosis was... ### What is your fix for the problem, implemented in this PR? My fix is to do the same thing that I did for `Molinillo`in https://github.com/bundler/bundler/pull/7210, but for `thor`. I don't intend to merge it right now, but I want to make sure that we are ready to support a new version of `thor` if they released right now. So, I can block this PR until a release is out. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 2f93a0d8a464b38f6b60b5707fa7f55603581994)
* Merge #7434Bundlerbot2019-11-111-1/+0
| | | | | | | | | | | | | | | | | | | 7434: More lazy loading and relative requires r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that testing the latest version of bundler as a vendored copy inside rubygems surfaced some more issues about requiring the wrong code, or activating default gems too early. ### What was your diagnosis of the problem? My diagnosis was that we should follow similar techniques I've used in other PRs: delay as much as possible requiring default gems, and don't rely on the LOAD_PATH for internal requires. ### What is your fix for the problem, implemented in this PR? My fix does just that, and also removes a bunch of `require`'s that were not necessary at all. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 147b9aa079f531ba5bf216d6d694fce5d36cfbfc)
* Version 2.1.0.pre.3David Rodríguez2019-11-071-1/+1
|
* Merge #7417Bundlerbot2019-11-071-2/+6
| | | | | | | | | 7417: Fix bundler/inline warning: method redefined; discarding old root r=deivid-rodriguez a=fatkodima Closes #6167 Co-authored-by: fatkodima <fatkodima123@gmail.com> (cherry picked from commit a1ecdbffceded635d615fc31d4823a2a67a8db0d)
* Merge #7416Bundlerbot2019-11-071-17/+12
| | | | | | | | | 7416: Don't use insecure temporary directory as home directory r=deivid-rodriguez a=fatkodima Closes #6501 Co-authored-by: fatkodima <fatkodima123@gmail.com> (cherry picked from commit ac758c84847a9850ae18226bfd5291e73e637ca3)
* Merge #7424Bundlerbot2019-11-071-1/+1
| | | | | | | | | | | | | | | | | 7424: Drop unnecessary `tempfile` require r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The `tempfile` dependency was dropped in [1], but the require was left in there. This could cause gem conflicts because `tempfile` requires `tmpdir` which requires `fileutils`, which loads the default gem instead of our namespaced version, and that could cause fileutils version mismatches and code overriding warnings. [1]: https://github.com/bundler/bundler/commit/4a37d66f3f222739178d798b30fb135f2429fe45 ### What is your fix for the problem, implemented in this PR? My fix is to drop the unnecessary require. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 0070d9fdddc027c0ee17662a1617e05b17331171)
* Merge #7393Bundlerbot2019-11-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 7393: Make 'bundle add' cache newly added gems when needed r=deivid-rodriguez a=andrehjr ### What was the end-user problem that led to this PR? The problem was that when calling `bundle add` with cache_all as true, I have to call an additional `bundle install` to vendor gems. ### What was your diagnosis of the problem? My diagnosis was that a call to Bundler.load.cache was missing. For example Bundler::CLI::Update does the same after installing gems. ### What is your fix for the problem, implemented in this PR? My fix was to call Bundler.load.cache when `Bundler.app_cache.exist? ` ### Why did you choose this fix out of the possible options? I chose this fix because it looks like this makes the behavior consistent with other commands. I should also say that, as this is my first PR here, I'm not sure that this is the best solution, and it seems an easy fix for #7384. Co-authored-by: André Luis Leal Cardoso Junior <andrehjr@gmail.com> (cherry picked from commit f83412ae8cda9c933b8cf33ec2abfb78a408daab)
* Merge #7394Bundlerbot2019-11-072-0/+65
| | | | | | | | | | | 7394: Add inline RDoc documentation r=hsbt a=zverok Since Bundler became part of the standard library, it renders in Ruby's docs. Unfortunately, what renders there... is not really helpful: https://docs.ruby-lang.org/en/master/Bundler.html I've added rudimentary documentation for `Bundler` module and two of its most user-facing methods to solve this problem at least partially. Co-authored-by: zverok <zverok.offline@gmail.com> (cherry picked from commit a7cc4ec87f17e549a1f0fb9063c53a76889426d6)
* Merge #7398Bundlerbot2019-11-071-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7398: Remove unnecessary lines from `bundler/setup` r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? These lines in the `bundler/setup` file are not necessary. ### What was your diagnosis of the problem? Bundler no longer needs to be in the `$LOAD_PATH` once a version of itself has been loaded. In any case, the `Metadata` source takes care of adding `bundler` to the index: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/source/metadata.rb#L13-L30 and then that spec is added to the resolution here: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/definition.rb#L180-L184 And from the resulting set of specs, the `$LOAD_PATH` is setup: https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/runtime.rb#L25-L38 So `bundler` will be present in the `$LOAD_PATH` anyways, and the lines being removed here will never be useful. ### What is your fix for the problem, implemented in this PR? My fix is to remove these lines to make the code easier to follow. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit bf7df421ee6311fcc17e6dc46d204236f33b4b3f)
* Merge #7401Bundlerbot2019-11-079-40/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 1a585f5cd760ae4be6930fd38d262677faa3694c)
* Merge #7388Bundlerbot2019-11-071-11/+46
| | | | | | | | | | | | | | | | | | | 7388: Fix help with command aliases r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the output of `bundle help install` and `bundle install --help` was inconstent with `bundle i --help`, and the same issue with all of the other command aliases. ### What was your diagnosis of the problem? My diagnosis was that the command reformatting so that `bundle <cmd> --help` "redirects" to `bundle help <cmd>` was ignoring command aliases. ### What is your fix for the problem, implemented in this PR? My fix is to make this logic aware of command aliases. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 5bc9c5868307679b79cdb7e4026da5f9e3888c63)
* Merge #7389Bundlerbot2019-11-072-13/+11
| | | | | | | | | | | | | | | | | | | 7389: Wrap up `bundle cache` migration to current `bundle package` r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that after https://github.com/bundler/bundler/pull/7249, we added the current `bundle package` functionality to the current `bundle cache` command, so that these commands are now aliases of each other. The initial plan was to do this in a more careful manner but we concluded that this was only _adding_ functionality to `bundle cache`, so not backwards incompatible. We still need to wrap up the original plan, where `bundle cache` is the preferred command. ### What is your fix for the problem, implemented in this PR? My fix is to migrate docs, tests and help text to use `bundle cache`, and to remove duplicated specs for `bundle cache` and `bundle package`, since they are testing the exact same code. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 5ba1360de631e2fabf2bfa998b104c4355c58b13)
* Merge #7386Bundlerbot2019-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | 7386: Suppress `Warning: no department given for MutableConstant` r=colby-swandale a=koic This PR suppresses the following `Warning: no department given for MutableConstant`. ```console % cd path/to/bundler % bundle exec rubocop -v 0.75.1 % bundle exec rubocop --parallel (snip) /Users/koic/src/github.com/bundler/bundler/lib/bundler/gem_helpers.rb: Warning: no department given for MutableConstant. Run `rubocop -a --only Migration/DepartmentName` to fix. ``` Co-authored-by: Koichi ITO <koic.ito@gmail.com> (cherry picked from commit bb6edfa90155b9ba66e3a66605bb1651cf35e359)
* Merge #7385Bundlerbot2019-11-075-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | 7385: Remove taint usage on Ruby 2.7+ r=hsbt a=jeremyevans ### What was the end-user problem that led to this PR? Ruby 2.7 is deprecating taint support. See https://bugs.ruby-lang.org/issues/16131 for details. ### What was your diagnosis of the problem? Bundler still uses `untaint` in a few places, which will cause deprecation warnings on Ruby 2.7. ### What is your fix for the problem, implemented in this PR? `s/\.untaint/.tap{|x| x.untaint if RUBY_VERSION < "2.7" }/g` ### Why did you choose this fix out of the possible options? It seemed simplest. Co-authored-by: Jeremy Evans <code@jeremyevans.net> (cherry picked from commit fcb0fef62096bd8d64383f5bbfa584ce77f40fd8)
* Merge #7375Bundlerbot2019-11-072-109/+132
| | | | | | | | | | | | | | | | | | | 7375: Bump vendored fileutils to 1.3.0 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we were not using a released version of fileutils. ### What was your diagnosis of the problem? My diagnosis was that we can upgrade, because 1.3.0 has been released. ### What is your fix for the problem, implemented in this PR? My fix is to upgrade. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit fe5d24b5dc6614c0edfee8407acba14aa610ac72)
* Merge #7374Bundlerbot2019-11-071-1/+1
| | | | | | | | | 7374: Fix typos r=hsbt a=biow0lf Fix typos Co-authored-by: Igor Zubkov <igor.zubkov@ag-force.com> (cherry picked from commit d4993be66fa2e76b3ca00ea56a51ecab5478b726)
* Merge #7361Bundlerbot2019-11-072-6/+15
| | | | | | | | | | | | | | | | | | | | | | | 7361: Add caller information to some deprecation messages r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that some deprecations mention usage of deprecated methods, but include no information about where the deprecated method is being called. ### What was your diagnosis of the problem? My diagnosis was that we should include this information with this kind of deprecation messages, to make migration easier. ### What is your fix for the problem, implemented in this PR? My fix is to add an optional argument to the `major_deprecation` method, to print the location of the deprecated caller. ### Why did you choose this fix out of the possible options? I chose this fix because it required little code changes. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit e719a58b26e2f85c885a950d90c8d4a0f7339c0f)
* Version 2.1.0.pre.2release/2.1.0.pre.2David Rodríguez2019-09-151-1/+1
|
* Merge #7344Bundlerbot2019-09-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 7344: Backport the latest ruby core changes r=hsbt a=hsbt ### What was the end-user problem that led to this PR? The master branch of Bundler with Ruby 2.7 fails some of tests. ### What was your diagnosis of the problem? It caused by deprecation warnings of Ruby 2.7 and some environmental issues. ### What is your fix for the problem, implemented in this PR? I fixed them. * rspec examples of Bundler failed randomly on GitHub Actions of ruby/ruby. We fixed it on `spec_group.rb` * `github_action_linux` label is no longer required. The current test suite is all green status with GitHub Actions. * The keyword separation feature warns stub code under the `inline_spec.rb`. I ignore them. ### Why did you choose this fix out of the possible options? Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org> Co-authored-by: Kazuhiro NISHIYAMA <zn@mbf.nifty.com> (cherry picked from commit cb5b0b6f43ceaee283c6cde084664c69f231e3fd)
* Merge #7340Bundlerbot2019-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 7340: Fix bundle clean issue r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundle clean` is crashing under some conditions. ### What was your diagnosis of the problem? My diagnosis was that sometimes (when the bundle includes git sourced gems with extensions), it assumes that some paths exist, but they don't. ### What is your fix for the problem, implemented in this PR? My fix is to ignore those paths. ### Why did you choose this fix out of the possible options? I chose this fix because it fixes the issue. Fixes #7338. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit b007fde67c77c1f15f13b97eda186644c2a2be04)
* Merge #7337Bundlerbot2019-09-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 7337: Fix a couple of bundler issues with keyword argument separation r=hsbt a=jeremyevans ### What was the end-user problem that led to this PR? `make test-bundler` in Ruby repository failed with recent changes to separate keyword arguments from positional arguments (see https://bugs.ruby-lang.org/issues/14183). ### What was your diagnosis of the problem? Bundler's specs check for lack of warnings, and the new changes cause warnings that cause Bundler's specs to fail. ### What is your fix for the problem, implemented in this PR? In one case, I fix the code to work with keyword arguments and positional arguments in positional arguments. In the other case, I fix the spec to ignore the keyword argument separation warnings. I fixed this upstream in Ruby already (https://github.com/ruby/ruby/commit/b5b3afadfab4072f55320075ccac6afe333a140c). So this is a request to make bundler use the same patch. You can certainly fix it differently, and there are more related issues to fix I think (they just don't cause test failures yet). The issues definitely need to be fixed if you want bundler's specs to run correctly in Ruby 2.7. ### Why did you choose this fix out of the possible options? Because it was the least amount of effort. Co-authored-by: Jeremy Evans <code@jeremyevans.net> (cherry picked from commit 8b61b4b380b734a5cedc31985902c45971255e3b)
* Merge #7307Bundlerbot2019-08-271-3/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7307: Deprecate `--path` flag to `bundle check` (and related fixes) r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that this flag should also be deprecated for these commands in preparation for bundler no longer remembering CLI flags. ### What was your diagnosis of the problem? My diagnosis was that, on bundler 3, the standard use case for `bundle check --path` will no longer work, namely: ``` $ bundle check --path .bundle The following gems are missing * rake (12.3.3) Install missing gems with `bundle install` $ bundle install Fetching gem metadata from https://rubygems.org/. Installing rake 12.3.3 Using bundler 2.1.0.pre.1 Bundle complete! 1 Gemfile dependency, 2 gems now installed. Bundled gems are installed into `./.bundle` ``` In the case of `bundle cache --path`, it has never really work as I expect So we should deprecate `bundle check --path` and instead use whatever path is configured. The cache of `bundle cache --path` is not as clear. Currently it does remember the flag for subsequent `bundle install` runs, but it does not change the location where subsequent `bundle cache` or `bundle install` runs save their cache. So I'm not sure how the current behavior is useful. ### What is your fix for the problem, implemented in this PR? My fix is, pending further discussion on what the expected behavior for `bundle cache` is, to only deprecate `bundle check --path`, and in the case of `bundle cache` I only fixed the option description to not say it remembers the option in bundler 3. Finally, I added a minor change in the deprecation message to recommend `bundle config set path <path>` instead of `bundle config path <path>`, because the latter is deprecated. ### Why did you choose this fix out of the possible options? I chose this fix because it's the subset of all this that seemed clearly like the way to go. Fixes #7300. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * 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.
* | Revert "Add all platforms to lockfile by default"undo_auto_multiplatformDavid Rodríguez2019-08-262-9/+1
| | | | | | | | This reverts commit 3dc509e645abb497e4dc92a7c42be471ff87db0b.
* | Revert "Remove now meaningless warning"David Rodríguez2019-08-261-1/+11
| | | | | | | | This reverts commit 00b095b98fe4bd44950beaf3bc9f1d91eac7b69e.
* | Revert "Remove now meaningless setting"David Rodríguez2019-08-262-1/+2
| | | | | | | | This reverts commit 52c5a0eedec34b5d86464b3cf135dc2002486f1d.
* | Revert "Remove now unused method"David Rodríguez2019-08-261-0/+4
| | | | | | | | This reverts commit 3a2d2f025081755bdb38af660897e7b2f749a33a.
* | Merge #7324Bundlerbot2019-08-232-7/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | 7324: Remove `:ruby_core` tag for ruby core r=hsbt a=hsbt This pull request is backported from https://github.com/ruby/ruby/pull/2380 Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Fix some bundler specs (#2380)David Rodríguez2019-08-232-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * These seem to consistenly pass already * Show actual command when running `make test-bundler` Current the setup command that installs the necessary gems for testing bundler was printed, but not the actual command that runs the tests. That was a bit confusing. * Borrow trick from setproctitle specs * A title that long doesn't get set sometimes No idea why, but the test doesn't need that the title is that long. * Fix most gem helper spec ruby-core failures * Fix the rest of the gem helper failures * Fix version spec by improving the assertion * Remove unnecessary `BUNDLE_RUBY` environment var We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name because bundler considers `BUNDLE_*` variables as settings. * Rename `BUNDLE_GEM` to `GEM_COMMAND` This is more descriptive I think, and also friendlier for bundler because `BUNDLE_` env variables are interpreted by bundler as settings, and this is not a bundler setting. This fixes one bundler spec failure in config specs against ruby-core. * Fix quality spec when run in core Use the proper path helper. * Fix dummy lib builder to never load default gems If a dummy library is named as a default gem, when requiring the library from its executable, the default gem would be loaded when running from core, because in core all default gems share path with bundler, and thus they are always in the $LOAD_PATH. We fix the issue by loading lib relatively inside dummy lib executables. * More exact assertions Sometimes I have the problem that I do some "print debugging" inside specs, and suddently the spec passes. This happens when the assertion is too relaxed, and the things I print make it match, specially when they are simple strings like "1.0" than can be easily be part of gem paths that I print for debugging. I fix this by making a more exact assertion. * Detect the correct shebang when ENV["RUBY"] is set * Relax assertion So that the spec passes even if another paths containing "ext" are in the load path. This works to fix a ruby-core issue, but it's a better assertion in general. We just want to know that the extension path was added. * Use folder structure independent path helper It should fix this spec for ruby-core. * Fix the last failing spec on ruby-core * Skip `bundle open <default_gem>` spec when no default gems
* | | Fix comments and messages to refer to https urlTakayuki Nakata2019-08-217-10/+10
|/ /
View Lorry Controller Status