summaryrefslogtreecommitdiff
path: root/spec/bundler
Commit message (Collapse)AuthorAgeFilesLines
* Merge https://github.com/rubygems/rubygems/pull/6655 manually.Hiroshi SHIBATA2023-05-101-7/+35
|
* Relax regexp for console assertionHiroshi SHIBATA2023-05-092-2/+2
|
* [rubygems/rubygems] Revert "Bundler::YAMLSerializer.load couldn't raise ↵Hiroshi SHIBATA2023-04-201-0/+23
| | | | | | | | error when invalid yaml was provided" This reverts commit https://github.com/rubygems/rubygems/commit/cfcfde04c783. https://github.com/rubygems/rubygems/commit/ac21ae7083
* [rubygems/rubygems] Bundler::YAMLSerializer.load couldn't raise error when ↵Hiroshi SHIBATA2023-04-191-23/+0
| | | | | | invalid yaml was provided https://github.com/rubygems/rubygems/commit/cfcfde04c7
* Removed file that is part of d89cc317c642848008f5b17a82196d25ddcdf124Hiroshi SHIBATA2023-04-111-16/+0
|
* [rubygems/rubygems] Remove one fallback to full indexes on big gemfilesDavid Rodríguez2023-04-074-32/+8
| | | | | | | | | | | | | | | | | | | If Gemfile has a lot of dependencies, we have an optimization that uses the full index in that case, assuming it's going to be faster. I think this is an old optimization that predates compact index API times, I believe we no longer need it these days. Also, since a few releases ago we check for circular dependencies when resolving by looping through all versions of each name and removing those that have circular dependencies that would trip up the resolver. This loop becomes actually very slow when full indexes are used because to find dependencies of a gemspec, we need to explicitly fetch the marshaled gemspec (`gemspec.rz` endpoint) for it, so the optimization has the opposite effect of making things very slow. https://github.com/rubygems/rubygems/commit/2f46289bd3
* [rubygems/rubygems] Fix resolver hangs when dealing with an incomplete lockfileDavid Rodríguez2023-04-061-0/+23
| | | | | | | | | | | | | | | | While working on locking multiple platforms by default, I got an infinite resolution loop in one of our resolver specs. The culprit ended up being that when dealing with lockfile specs with incomplete dependencies (spec appears in lockfile, but its dependencies don't), those specs were not being properly expired and that tripped up resolution. The issue for some reason only manifests when dealing with multiple lockfile platforms, that's why it only manifested when working on locking multiple platforms by default. https://github.com/rubygems/rubygems/commit/4ca72913bb
* [rubygems/rubygems] Onboard Rubocop Naming/MemoizedInstanceVariableName rule ↵Josef Šimánek2023-03-281-5/+5
| | | | | | to Bundler. https://github.com/rubygems/rubygems/commit/d768be0c65
* [rubygems/rubygems] Fix installing plugins in frozen modeDavid Rodríguez2023-03-281-0/+7
| | | | | | Plugins don't use a lockfile, so ignore frozen related settings. https://github.com/rubygems/rubygems/commit/f17a3bb81f
* [rubygems/rubygems] Fix incorrect removal of "ruby" platform from lockfileDavid Rodríguez2023-03-281-0/+50
| | | | | | | | | | | | When dependencies have changed, we'll be re-resolving, and we can't really know whether the resolution will be valid or invalid for the Ruby platform, so skip the removal in that case. The fix worked, but made some other specs fail, and surfaced that the `@dependencies_changed` attribute was actually being incorrect set when explicitly unlocking. Fixed that with an early return. https://github.com/rubygems/rubygems/commit/20d8f5e5d9
* [rubygems/rubygems] Fix unnecessary downgrade of top level dependency when ↵David Rodríguez2023-03-281-0/+83
| | | | | | | | | | | | | | | | | | | | | | | unlocking Bundler is very conservative by default, trying to preserve versions from the lockfile as possible, and never downgrading them. However, when it runs into a resolution error, it still tries to find a valid resolution. This fallback behavior was too "brute-force" though, completely unrestricting any gem found in the resolution conflict, and that could lead to direct dependencies being downgraded in some edge cases. Instead, unlock things a bit more carefully: * First try unlocking fully pinned indirect dependencies, but leave a lower bound requirement in place to prevent downgrades. * Then try unlocking any fully pinned dependency, also leaving a lower bound requirement in place. * Finally completely unrestrict dependencies if nothing else worked. https://github.com/rubygems/rubygems/commit/7f55ed8302
* [rubygems/rubygems] Rewrite GemVersionPromoter specsMichael Siegfried2023-03-281-124/+111
| | | | | | | | | | | | | | | Add tests for pre, move more of the setup into a helper method, and restructure tests. There seem to be five considerations for these tests (level, pre, strict, locked, and whether the current version is a prerelease version, though the last one overlaps with pre and didn't seem to behave how I expected under test). Rather than write out the 16 (/32 if the last consideration is real) combinations, I wrote most with independent tests for each value. The existing combined tests were maintained (level vs strict) because these seem the most interrelated. https://github.com/rubygems/rubygems/commit/74c23a91b2
* Don't suggest `--full-index` on API Response mismatch errorsDavid Rodríguez2023-03-232-2/+2
| | | | | | | I've never seen this error in real life, and if it was happening, I think it's either some server side issue that would need to be fixed or some transient issue. We should move away from the full index, since it's slow, so let's stop recommending it.
* Fix logging the fallback to the full index on GemspecError'sDavid Rodríguez2023-03-231-10/+6
| | | | | | The debug message suggests retrying using `--full-index`, but the retry is happening automatically. Just log that we are falling back to the full index, like we do with other errors.
* Don't remove RUBY platform when healing a lockfile with missing specsDavid Rodríguez2023-03-231-39/+53
|
* Don't remove RUBY platform when healing a lockfile with missing specsDavid Rodríguez2023-03-232-2/+6
|
* [rubygems/rubygems] Use indented heredocNobuyoshi Nakada2023-03-225-11/+11
| | | | https://github.com/rubygems/rubygems/commit/085d2776d8
* When running `bundle lock --update <name>`, checkout locked revision of ↵David Rodríguez2023-03-171-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | unrelated git sources directly Since Bundler 2.4, we will try to checkout any branch specified in the Gemfile, while until Bundler 2.3 we would directly checkout the locked revision. This should not make any difference in most situations, but in some edge cases, like if the branch specified in the `Gemfile` has been renamed, but the locked revision still exist, it causes an error now while before it would update the lockfile without issues. I debated which behavior was best, since I was not sure. But my conclusion is that if the situation does not require expiring the lockfile source in favor of the Gemfile source, we should use the locked revision directly and proceed happily. So I restored Bundler 2.3 behavior. I think this is consistent with how yanked gems are handled, for example. Of course, if explicitly updating the git source itself, or all gems, we will still get any errors like missing branches related to the git source.
* Don´t consider platform specific candidates when `force_ruby_platform` setDavid Rodríguez2023-03-171-0/+48
| | | | | | | | This was working fine for direct dependencies using `force_ruby_platform` explicitly through Gemfile, but not for indirect dependencies. In general, indirect dependencies do not have this property set, but in truffleruby this is different and the default value is to have it set.
* Don't ignore pre-releases when there's only one candidateDavid Rodríguez2023-03-171-0/+25
| | | | | | | | | This should be a very rare edge case, however, it does happen when using a .dev version of Bundler because in that case, that's the only version that the resolver considers, and it should not be ignored. We could've special cased this specifically for Bundler, but I think it does make sense for every gem.
* Normalize git sourcesDavid Rodríguez2023-03-171-0/+18
| | | | | Just like gem sources, a "style-only" change, like adding a trailing slash, should not expire them.
* [rubygems/rubygems] Fix incorrect error message when multiple platforms are ↵David Rodríguez2023-03-171-0/+6
| | | | | | locked https://github.com/rubygems/rubygems/commit/24d2bf9cb2
* [rubygems/rubygems] Remove unnecessary `specific_local_platform` test helperDavid Rodríguez2023-03-179-37/+33
| | | | https://github.com/rubygems/rubygems/commit/86b574824d
* [rubygems/rubygems] Simplify `lockfile_platforms` helperDavid Rodríguez2023-03-176-12/+8
| | | | | | To make it easier to change the default platforms that get locked later. https://github.com/rubygems/rubygems/commit/255c4012ec
* [rubygems/rubygems] Remove unnecessary `local` helperDavid Rodríguez2023-03-173-7/+3
| | | | https://github.com/rubygems/rubygems/commit/27ed6870ce
* [rubygems/rubygems] Use more common linux platform for specsDavid Rodríguez2023-03-172-3/+3
| | | | https://github.com/rubygems/rubygems/commit/3841a58095
* [rubygems/rubygems] Use splatted args to `lockfile_platforms_for`David Rodríguez2023-03-175-6/+6
| | | | | | Nicer :) https://github.com/rubygems/rubygems/commit/c0ab2893c3
* [rubygems/rubygems] Applied Layout/SpaceAroundOperators copHiroshi SHIBATA2023-03-162-2/+2
| | | | https://github.com/rubygems/rubygems/commit/3139587be9
* [rubygems/rubygems] Use OpenSSL::Digest instead of digest stdlibHiroshi SHIBATA2023-03-151-2/+2
| | | | https://github.com/rubygems/rubygems/commit/69aa007679
* [rubygems/rubygems] Use `RbSys::ExtensionTask` when creating new rust gemsIan Ker-Seymer2023-03-101-2/+2
| | | | https://github.com/rubygems/rubygems/commit/125f9fece9
* [rubygems/rubygems] Respect --no-install option for git: sourcesJulie Haehn2023-03-071-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the --no-install option to `bundle package` is totally ignored for git sources. This can have very strange effects if you have: - a git-sourced gem, - with native extensions, - whose extconf.rb script depends on another gem, - which is installed from Rubygems in the gemfile. In that circumstance, `bundle package --no-install --all` will download the Rubygems dependencies to `vendor/cache` but NOT install them. It will also check out the git gems to `vendor/cache` (good), and attempt to build their native extensions (bad!). The native extension build will fail because the extconf.rb script crashes, since the dependency it needs is missing. I implemented a fix for this in `source/git.rb`, since this is analogous to what's happening in `source/rubygems.rb`. I do admit though the whole thing is a little strange though - an "install" method that.... proceeds to look at a global flag to not install anything. Add test to confirm cache respects the --no-install flag https://github.com/rubygems/rubygems/commit/5a77d1c397 Co-authored-by: KJ Tsanaktsidis <kj@kjtsanaktsidis.id.au>
* [rubygems/rubygems] Better suggestion when `bundler/setup` fails due to ↵David Rodríguez2023-03-071-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | missing gems If the original `BUNDLE_GEMFILE` is different from the default, then the suggestion wouldn't work as is. Before: ``` $ util/rubocop Could not find rubocop-1.30.1 in locally installed gems Run `bundle install` to install missing gems. $ rubygems git:(better-cmd-suggestion) ✗ bundle install Could not locate Gemfile ``` After: ``` $ util/rubocop Could not find rubocop-1.30.1 in locally installed gems Run `bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb` to install missing gems. $ bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb Fetching gem metadata from https://rubygems.org/......... Using ast 2.4.2 Using bundler 2.4.7 Using parser 3.1.2.0 Using rainbow 3.1.1 Using parallel 1.22.1 Using regexp_parser 2.5.0 Using rubocop-ast 1.18.0 Using rexml 3.2.5 Using ruby-progressbar 1.11.0 Using unicode-display_width 2.1.0 Fetching rubocop 1.30.1 Installing rubocop 1.30.1 Using rubocop-performance 1.14.2 Bundle complete! 2 Gemfile dependencies, 12 gems now installed. Use `bundle info [gemname]` to see where a bundled gem is installed. $ util/rubocop Inspecting 345 files ......................................................................................................................................................................................................................................................................................................................................................... 345 files inspected, no offenses detected ``` https://github.com/rubygems/rubygems/commit/bf1320d805
* [rubygems/rubygems] Alias CurrentRuby#mswin?, mswin64?, mingw?, x64_mingw? ↵johnnyshields2023-03-034-6/+19
| | | | | | to #windows?. (This is done instead of logging a deprecation warning.) https://github.com/rubygems/rubygems/commit/b9fcc7c0ab
* [rubygems/rubygems] Replace lockfile with `.locked`Tony Hsu2023-03-021-0/+31
| | | | https://github.com/rubygems/rubygems/commit/203f3e3802
* [rubygems/rubygems] Regenerate lockfile if spec list is invalid/empty.Ellen Marie Dash2023-03-021-0/+51
| | | | https://github.com/rubygems/rubygems/commit/d2c56315e2
* [rubygems/rubygems] Auto-heal on corrupted lockfile with missing depsDaniel Colson2023-03-011-4/+19
| | | | | | | | | | | | | | | | | | | Following up on https://github.com/rubygems/rubygems/pull/6355, which turned a crash into a nicer error message, this commit auto-heals the corrupt lockfile instead. In this particular case (a corrupt Gemfile.lock with missing dependencies) the LazySpecification will not have accurate dependency information, we have to materialize the SpecSet to determine there are missing dependencies. We've already got a way to handle this, via `SpecSet#incomplete_specs`, but it wasn't quite working for this case because we'd get to `@incomplete_specs += lookup[name]` and `lookup[name]` would be empty for the dependency. With this commit we catch it a bit earlier, marking the parent spec containing the missing dependency as incomplete. https://github.com/rubygems/rubygems/commit/486ecb8f20
* [rubygems/rubygems] lint fix againMercedes Bernard2023-02-231-1/+1
| | | | https://github.com/rubygems/rubygems/commit/118d28ad27
* [rubygems/rubygems] lint fixMercedes Bernard2023-02-231-7/+7
| | | | https://github.com/rubygems/rubygems/commit/de3b69f1a7
* [rubygems/rubygems] add safe_load_marshal for gem::version and gem::specMercedes Bernard2023-02-231-0/+12
| | | | https://github.com/rubygems/rubygems/commit/2ea2ead1b3
* [rubygems/rubygems] test Bundler::Fetcher that error raised when attempting ↵Mercedes Bernard2023-02-231-0/+30
| | | | | | load unexpected class https://github.com/rubygems/rubygems/commit/795e796a9e
* [rubygems/rubygems] test rubygems_integration that error raised when ↵Mercedes Bernard2023-02-231-0/+11
| | | | | | attempting load unexpected class https://github.com/rubygems/rubygems/commit/9798718b3b
* [rubygems/rubygems] add test for private load_marshal methodMercedes Bernard2023-02-231-0/+5
| | | | https://github.com/rubygems/rubygems/commit/3a772125b8
* [rubygems/rubygems] make Bundler.load_marshal privateMercedes Bernard2023-02-231-2/+2
| | | | https://github.com/rubygems/rubygems/commit/4909d071d2
* Merge rubygems/bundler masterHiroshi SHIBATA2023-02-216-7/+124
| | | | Pick from https://github.com/rubygems/rubygems/commit/e9304aed7e43308b99e70c2f7b92028315fee8a5
* [rubygems/rubygems] Give a better message when Gemfile branch does not existDavid Rodríguez2023-02-212-4/+17
| | | | https://github.com/rubygems/rubygems/commit/cb4fc41cbc
* [rubygems/rubygems] Fix crash in pub grub involving empty rangesDavid Rodríguez2023-02-212-1/+67
| | | | https://github.com/rubygems/rubygems/commit/0f168516f7
* [rubygems/rubygems] Update pub_grubJohn Hawthorn2023-02-214-6/+6
| | | | | | | | | * Replaces the wording of "is forbidden" with "cannot be used" * Fixes the method signature of VersionRange::Empty#eql? https://github.com/rubygems/rubygems/commit/8c6b3f130b Co-authored-by: Daniel Colson <danieljamescolson@gmail.com>
* [rubygems/rubygems] Sync with pub_grub main branchDavid Rodríguez2023-02-211-1/+1
| | | | | | We became a bit out of sync lately. https://github.com/rubygems/rubygems/commit/6161a2610a
* [rubygems/rubygems] Restore better error message when locked ref does not existDavid Rodríguez2023-02-211-0/+27
| | | | https://github.com/rubygems/rubygems/commit/c8e024359f
* [rubygems/rubygems] Avoid crashing with a corrupted lockfileDaniel Colson2023-02-092-2/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I did a bad thing (script that edits the Gemfile.lock directly) and ended up with a Gemfile.lock that was completely missing some indirect dependencies. While this is my fault and an error is reasonable, I noticed that the error got progressively less friendly in recent versions of bundler. Something similar came up in https://github.com/rubygems/rubygems/issues/6210, and this commit would have helped with that case as well (although we've already handled this a different way with #6219). Details: --- Back on Bundler 2.2.23, a corrupt lockfile like this would cause a helpful error: ``` Unable to find a spec satisfying minitest (>= 5.1) in the set. Perhaps the lockfile is corrupted? ``` Bundler 2.3.26 gave a helpful warning: ``` Warning: Your lockfile was created by an old Bundler that left some things out. Because of the missing DEPENDENCIES, we can only install gems one at a time, instead of installing 16 at a time. You can fix this by adding the missing gems to your Gemfile, running bundle install, and then removing the gems from your Gemfile. The missing gems are: * minitest depended upon by activesupport ``` But then continued on and crashed while trying to report the unmet dependency: ``` --- ERROR REPORT TEMPLATE ------------------------------------------------------- NoMethodError: undefined method `full_name' for nil:NilClass lib/bundler/installer/parallel_installer.rb:127:in `block (2 levels) in check_for_unmet_dependencies' ... ``` Bundler 2.4.0 and up crash as above when jobs=1, but crash even harder when run in parallel: ``` --- ERROR REPORT TEMPLATE ------------------------------------------------------- fatal: No live threads left. Deadlock? 3 threads, 3 sleeps current:0x00007fa6b6704660 main thread:0x00007fa6b6704660 * #<Thread:0x000000010833b130 sleep_forever> rb_thread_t:0x00007fa6b6704660 native:0x0000000108985600 int:0 * #<Thread:0x0000000108dea630@Parallel Installer Worker #0 tmp/1/gems/system/gems/bundler-2.5.0.dev/lib/bundler/worker.rb:90 sleep_forever> rb_thread_t:0x00007fa6b67f67c0 native:0x0000700009a62000 int:0 * #<Thread:0x0000000108dea4a0@Parallel Installer Worker #1 tmp/1/gems/system/gems/bundler-2.5.0.dev/lib/bundler/worker.rb:90 sleep_forever> rb_thread_t:0x00007fa6b67f63c0 native:0x0000700009c65000 int:0 <internal:thread_sync>:18:in `pop' tmp/1/gems/system/gems/bundler-2.5.0.dev/lib/bundler/worker.rb:42:in `deq' ... ``` Changes --- This commit fixes the confusing thread deadlock crash by detecting if dependencies are missing such that we'll never be able to enqueue. When that happens we treat it as a failure so the install can finish. That gets us back to the `NoMethodError`, which this commit fixes by using a different warning in the case where no spec is found. https://github.com/rubygems/rubygems/commit/d73001a21d
View Lorry Controller Status