summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Use copy instead of movingci/fix_flakyDavid Rodríguez2020-01-181-1/+1
| | | | | | I'm not really sure why, but the rename syscall sometimes is raising Errno::EXDEV under Windows. I figure using a copy will fix the issue, and it stills reproduces the regression the test is meant to check for.
* Merge #7559Bundlerbot2020-01-172-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7559: Reactivate usused code for ruby version resolution r=deivid-rodriguez a=larskanis The code was changed in commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 so that RubyVersion.system was no longer respected. This is reactivated now and specs are adjusted accordingly. ### What was the end-user problem that led to this PR? Not known. ### What was your diagnosis of the problem? I read the bundler source code and noticed this. ### What is your fix for the problem, implemented in this PR? My fix re-adds the ruby version as it was before commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 , since it seems to be a mistake. ### Why did you choose this fix out of the possible options? As a alternative I added #7558 that removes the code in question. Co-authored-by: Lars Kanis <kanis@comcard.de>
| * Reactivate usused code for ruby version resolutionLars Kanis2020-01-162-4/+4
| | | | | | | | | | The code was changed in commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 so that RubyVersion.system was no longer respected. This is reactivated now and specs are adjusted accordingly.
* | Merge #7578Bundlerbot2020-01-172-2/+32
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7578: Don't ignore resolved platform information r=deivid-rodriguez a=kou This is a follow-up change of #7522. ### What was the end-user problem that led to this PR? The problem was installing wrong platform gem even when resolver resolves the correct platform gem. See also: * https://github.com/rubygems/bundler/pull/7522#issuecomment-574628275 * https://github.com/rubygems/bundler/pull/7522#issuecomment-574882536 ### What was your diagnosis of the problem? My diagnosis was `Bundler::LazySpecification#__materialize__` doesn't care about the resolved platform information. ### What is your fix for the problem, implemented in this PR? My fix cares about the resolved platform information. ### Why did you choose this fix out of the possible options? I chose this fix because we should respect the resolved platform information to install correct gem. Co-authored-by: Sutou Kouhei <kou@clear-code.com>
| * Don't use needless specific APISutou Kouhei2020-01-171-1/+1
| | | | | | Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
| * Revert MatchPlatform#platforms_match?Sutou Kouhei2020-01-172-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because some examples are failed: rspec ./spec/cache/gems_spec.rb:236 # bundle cache when previously cached doesn't remove gems that are for another platform rspec ./spec/commands/install_spec.rb:220 # bundle install with gem sources the simple case with a gem that installs multiple platforms installs gems for the local platform as first choice rspec ./spec/commands/update_spec.rb:39 # bundle update with --all updates the entire bundle rspec ./spec/commands/update_spec.rb:49 # bundle update with --all doesn't delete the Gemfile.lock file if something goes wrong rspec ./spec/commands/update_spec.rb:104 # bundle update with a top level dependency unlocks all child dependencies that are unrelated to other locked dependencies rspec ./spec/commands/update_spec.rb:115 # bundle update with an unknown dependency should inform the user rspec ./spec/commands/update_spec.rb:119 # bundle update with an unknown dependency should suggest alternatives rspec ./spec/commands/update_spec.rb:126 # bundle update with a child dependency should update the child dependency rspec ./spec/commands/update_spec.rb:299 # bundle update in a frozen bundle should suggest different command when frozen is set globally rspec ./spec/runtime/platform_spec.rb:60 # Bundler.setup with multi platform stuff will add the resolve for the current platform
| * Don't ignore resolved platform informationSutou Kouhei2020-01-173-3/+34
|/ | | | This is a follow-up change of #7522.
* Merge #7522Bundlerbot2020-01-1612-73/+183
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7522: Improve platform specific gem resolution r=deivid-rodriguez a=kou ### What was the end-user problem that led to this PR? Platform specific gems aren't resolved when platform specific gems are conflicted. For example, in the following situation, foo-1.0.0-x64-mingw32 that requires bar<1 is conflicted because there is no bar<1. Without this change, Bundler raises a conflict error. But users can use foo-1.0.0 (no x64-mingw32) in this situation. With this change, Bundler resolves to foo-1.0.0 (no x64-mingw32). ```ruby @index = build_index do gem "bar", "1.0.0" gem "foo", "1.0.0" gem "foo", "1.0.0", "x64-mingw32" do dep "bar", "< 1" end end dep "foo" platforms "x64-mingw32" ```` See also #6247. This change includes the specs that were added in #6247. ### What was your diagnosis of the problem? Not platform specific gem (foo-1.0.0 in the above case) isn't tried to be resolved when platform specific gem (foo-1.0.0-x64-mingw32 in the above case) is available. ### What is your fix for the problem, implemented in this PR? In this PR, not platform specific gem (foo-1.0.0 in the above case) is also tried to be resolved even when platform specific gem (foo-1.0.0-x64-mingw32 in the above case) is available. Priority is "platform specific gem" -> "not platform specific gem". So platform specific gem is usable, platform specific gem is used. Not platform specific gem is used as fallback. `search_for` represents this. Here is the `search_for` specification: https://github.com/bundler/bundler/blob/master/lib/bundler/vendor/molinillo/lib/molinillo/modules/specification_provider.rb#L11-L13 > Search for the specifications that match the given dependency. The specifications in the returned array will be considered in reverse order, so the latest version ought to be last. ## Why did you choose this fix out of the possible options? I choose this fix because this is based on Molinillo's specification. Co-authored-by: Lars Kanis <lars@greiz-reinsdorf.de> Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: Sutou Kouhei <kou@clear-code.com>
| * Remove needless ifSutou Kouhei2020-01-161-4/+5
| |
| * Add no required_ruby_version againSutou Kouhei2020-01-151-0/+17
| |
| * Sort available platformsSutou Kouhei2020-01-152-9/+10
| |
| * Always add a spec group for all platforms to candidatesSutou Kouhei2020-01-153-26/+34
| |
| * SpecGroup#to_specs doesn't return duplicated specsSutou Kouhei2020-01-152-1/+9
| |
| * Fix styleSutou Kouhei2020-01-151-2/+2
| |
| * Always add "ruby" version to selected spec groups as fallbackSutou Kouhei2020-01-152-6/+10
| |
| * Fix the name of Ruby requirementSutou Kouhei2020-01-151-2/+2
| | | | | | | | We should use "Ruby\0" instead of "ruby\0".
| * Rename SpecGroup#spec to SpecGroup#spec_forSutou Kouhei2020-01-152-4/+5
| |
| * Add SpecGroup#copy_forSutou Kouhei2020-01-152-12/+12
| |
| * Revert unskippable skipsSutou Kouhei2020-01-152-0/+14
| |
| * Try unskipping on WindowsSutou Kouhei2020-01-152-18/+0
| |
| * Add support for force_ruby_platform with specific_platform againSutou Kouhei2020-01-153-13/+19
| |
| * Don't set platforms to dependency registered by gemspecSutou Kouhei2020-01-154-49/+1
| | | | | | | | | | | | | | | | | | Platform related dependencies are resolved in Resolver now. So we don't need to register all available platforms explicitly. This reverts commit 0a8ca4879e0b79aa4109a0dc424940b079ef38d0. See also: #4150 and #4102
| * Update expected for specific_platform feature flags caseSutou Kouhei2020-01-152-4/+17
| | | | | | | | | | In this case, Bundler uses specific platform to resolve dependency. So error message includes specific platform information.
| * Add support for specific_platform feature flagSutou Kouhei2020-01-151-5/+10
| |
| * Add support for multiple platform spec group againSutou Kouhei2020-01-152-4/+31
| |
| * Improve platform specific gem resolutionSutou Kouhei2020-01-153-6/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It resolves #6247. This changes includes the patches that add (RSpec) specs for this situation in #6247. If there is a platform specific gem but it can't be resolved available version, Bundler reports an error. For example, @index = build_index do gem "bar", "1.0.0" gem "foo", "1.0.0" gem "foo", "1.0.0", "x64-mingw32" do dep "bar", "< 1" end end dep "foo" platforms "x64-mingw32" raises an error because foo-1.0.0-x64-mingw32 requires bar<1 but there isn't bar<1. With this change, foo-1.0.0 (no x64-mingw32) is used as fallback. Because foo-1.0.0 doesn't depend on bar<1.
| * Add a spec for when differing dependencies cause the generic version gem to ↵Samuel Giddins2020-01-151-0/+14
| | | | | | | | be the only option
| * Add two specs for choosing platform specific gemsLars Kanis2020-01-151-0/+29
| | | | | | | | The first spec succeeds, but the second spec fails currently.
* | Merge #7563Bundlerbot2020-01-163-140/+142
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7563: Adds documentation for BUNDLE_APP_CONFIG env var r=deivid-rodriguez a=dchandekstark Fixes #7085 ### What was the end-user problem that led to this PR? The problem was missing documentation. ### What was your diagnosis of the problem? N/A ### What is your fix for the problem, implemented in this PR? Provided some documentation. ### Why did you choose this fix out of the possible options? N/A Co-authored-by: David Chandek-Stark <david.chandek.stark@duke.edu>
| * | Adds documentation for BUNDLE_APP_CONFIG env varDavid Chandek-Stark2020-01-153-140/+142
|/ /
* | Merge #7575Bundlerbot2020-01-151-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7575: Fix travis-ci badge status r=hsbt a=teitei-tk ### What was the end-user problem that led to this PR? n/a ### What was your diagnosis of the problem? repository was transferred and url changed. ### What is your fix for the problem, implemented in this PR? update badge url for travis-ci in README.md ### Why did you choose this fix out of the possible options? n/a Co-authored-by: teitei-tk <teitei.tk@gmail.com>
| * update travis ci build badge urlteitei-tk2020-01-101-1/+1
| |
* | Merge #7561Bundlerbot2020-01-141-26/+13
|\ \ | | | | | | | | | | | | | | | | | | | | | 7561: Tweak UPGRADING.md r=deivid-rodriguez a=JunichiIto Fixed some issues in UPGRADING.md. I am not sure the link https://github.com/bundler/bundle-viz should be removed or not, but it could make readers confused (like me), so I removed it. It should be reverted when the link is available. Co-authored-by: Junichi Ito <jit@sonicgarden.jp>
| * | Tweak UPGRADING.mdJunichi Ito2020-01-141-26/+13
| |/
* | Merge #7554Bundlerbot2020-01-133-13/+245
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7554: Fix ruby version parsing in compact index r=deivid-rodriguez a=kou ### What was the end-user problem that led to this PR? The end-user can't use multiple Ruby version requirements (e.g. ">= 2.2, < 2.7.dev") provided by each gem to resolve suitable version. See also: https://github.com/bundler/bundler/pull/7522#issuecomment-571090513 ### What was your diagnosis of the problem? https://rubygems.org/info/ffi returns the following information: ```text 1.11.3-x86-mingw32 |checksum:99e4845796c8dec1c3fc80dc772860a01633b33291bd7534007f5c7724f0b876,ruby:>= 2.2, < 2.7.dev ``` The current parser doesn't parse the line correctly. It drops "< 2.7.dev" requirement for Ruby version. It means that the parsed requirement is "ruby >= 2.2" instead of "ruby >=2.2 && ruby < 2.7.dev". ### What is your fix for the problem, implemented in this PR? I implemented a new parsing logic for "requirements". It assumes that "requirements" has at most three fields: "checksum", "ruby" and "rubygems". Because https://github.com/rubygems/compact_index/blob/master/lib/compact_index/gem_version.rb#L26-L28 implements so. ### Why did you choose this fix out of the possible options? I chose this fix because it's difficult to implement generic parsing logic without "," escape in version. For example, "," leading to "2.2" and "," leading to "2.7.dev" in "ruby:>= 2.2, < 2.7.dev,rubygems:> 1.3.1" are conflict. We need to know field name such as "ruby" and "rubygems" to detect "," as field delimiter. "," in "dependencies" are escaped as "&": https://github.com/rubygems/compact_index/blob/master/lib/compact_index/gem_version.rb#L37 Co-authored-by: Sutou Kouhei <kou@clear-code.com>
| * | Fix instance variable nameSutou Kouhei2020-01-121-2/+2
| | |
| * | Fix ruby version parsing in compact indexSutou Kouhei2020-01-123-13/+245
| | | | | | | | | | | | | | | We can't use the same logic as "dependencies" for "requirements". Because "," in "requirements" isn't escaped as "&".
* | | Merge #7569Bundlerbot2020-01-131-0/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7569: Load `CompactIndexClient` upfront during specs 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 failing CI: https://github.com/rubygems/bundler/runs/386607433. ### What was your diagnosis of the problem? My diagnosis was that it could be caused by autoloading not being thread safe. The `CompactIndexClient` constant is autoloaded. If two parallel threads try to autoload the constant at the same time, it could happen that one of them sees the constant in an incomplete state (no `initialize` method defined yet). ### What is your fix for the problem, implemented in this PR? My fix is to load the constant upfront. ### Why did you choose this fix out of the possible options? I chose this fix because even if I could stop autoloading the constant, I don't want to touch code in `lib` at the moment just to fix a testing issue. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Load `CompactIndexClient` upfronttests/fix_autoload_thread_safety_issueDavid Rodríguez2020-01-131-0/+3
|/ / / | | | | | | | | | | | | | | | To prevent potential autoloading issues in our parallel tests. I think this could be the cause of https://github.com/rubygems/bundler/runs/386607433.
* | | Merge #7568Bundlerbot2020-01-1365-776/+654
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7568: Make parallel tests more stable r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that since we run parallel tests by default, our CI is much less stable even though specs are faster. ### What was your diagnosis of the problem? My diagnosis was that our specs change folders back and forth for every test, and that's not thread safe. ### What is your fix for the problem, implemented in this PR? My fix is to stop changing folders in the main process during our specs. ### Why did you choose this fix out of the possible options? I chose this fix because it should improve stability of our specs. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove global directory switching from specstests/less_flakynessDavid Rodríguez2020-01-1252-647/+511
| | | | | | | | | | | | | | | | | | | | | | | | `Dir.chdir` is not thread safe, so it makes our parallel specs flaky. Instead, use the following alternatives: * Use `:chdir` parameter to `Open3` methods for specs that shell out. * Stub `find_gemfile` or other relevant helpers for unit tests.
| * | Make warnings spec independent of LOAD_PATHDavid Rodríguez2020-01-121-3/+3
| | |
| * | Don't load default URI gem during specsDavid Rodríguez2020-01-122-2/+2
| | |
| * | Extract `man_tracked_files` path helperDavid Rodríguez2020-01-123-2/+8
| | |
| * | Pass a generic options hash to `sys_exec`David Rodríguez2020-01-125-9/+9
| | | | | | | | | | | | For consistency with the rest of helpers.
| * | Simplify `gem_command` to pass full args to `gem` togetherDavid Rodríguez2020-01-122-6/+6
| | |
| * | Extract `bundled_app_gemfile` path helperDavid Rodríguez2020-01-1211-40/+44
| | |
| * | Extract `bundled_app_lock` path helperDavid Rodríguez2020-01-1219-81/+85
|/ /
* | Merge #7565Bundlerbot2020-01-111-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7565: Lock rack to 2.0.8 for tests r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was CI is failing due to a rack warning. ### What was your diagnosis of the problem? My diagnosis was that our CI shouldn't break because of third party changes. ### What is your fix for the problem, implemented in this PR? My fix is to lock the rack version our tests use. ### Why did you choose this fix out of the possible options? I chose this fix because it gives us a more deterministic test environment, which is good. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Lock rack to 2.0.8 for teststests/lock_rackDavid Rodríguez2020-01-111-1/+1
|/
View Lorry Controller Status