Repository navigation
Read Windows system info natively instead of via PowerShell - #250
Merged
cursor[bot] merged 4 commits intoSep 11, 2026
Merged
Conversation
Follow-up to fetchcord#245, where the stated goal was to use fastfetch where native is not implemented yet and keep it as the fallback. This starts that on Windows, and orders the providers accordingly. On Windows the CommandProvider shells out once per field. Each of those is a PowerShell start-up, and the fan-out across the command table dominates the time to first presence. Reading the same values from the registry costs a few milliseconds and needs nothing installed. Adds fetchers under fetch_cord/native/Windows/ for os, kernel, cpu, motherboard, host and mem, alongside the existing packages one. Each returns exactly what its PowerShell command returned, so the values stay interchangeable: os Microsoft Windows 11 Pro (Win32_OperatingSystem.Caption) kernel 10.0.26100 (Win32_OperatingSystem.Version) cpu Intel(R) Core(TM) i7-... (Win32_Processor.Name) motherboard ASUSTeK COMPUTER INC. (Win32_BaseBoard.Manufacturer) host PRIME B760-PLUS D4 (Win32_BaseBoard.Product) mem 12.40 GB / 31.92 GB (same format as the command) Providers are now ordered native, fastfetch, commands on every platform. That is safe because a native fetcher returns None when it is not confident rather than guessing - an unreadable registry key, or firmware boilerplate like "To Be Filled By O.E.M." - so Fetch.snapshot's existing gap-filling hands the field straight to fastfetch. Native coverage can then grow one field at a time without any platform losing detail it has today. Nothing changes on Linux or macOS, where no native fetchers exist yet. Two details worth knowing: - The registry's ProductName still reads "Windows 10 Pro" on Windows 11, so the build number decides the release and the name is corrected to match what WMI reports. - Firmware placeholders are reported as absent rather than shown. Also fixes native fetch() stringifying None into the literal "None", which was harmless while packages was the only fetcher. Tests fake the registry at the fetcher boundary, so all of them run on a non-Windows CI runner. One asserts the native path makes no subprocess calls, keeping "this adds no dependencies" verifiable rather than a claim.
fake_registry was annotated -> MagicMock but returned patch(...), which is a _patch object. Only used as a context manager, so make it one with @contextmanager and type it Iterator[MagicMock]. Caught by CI's "mypy fetch_cord tests" - the suite is type checked too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WB6HG4WLukGEjhcq8FZJ7A
…95ef Co-authored-by: BlivionIaG <BlivionIaG@users.noreply.github.com>
Align with fetchcord#243 so the host cycle still gets a board-model string for id matching when NativeProvider wins over the PowerShell command. Co-authored-by: BlivionIaG <BlivionIaG@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #245, where the stated goal was to use fastfetch where native is not implemented yet and keep it as the fallback. This starts that on Windows, and orders the providers accordingly.
On Windows the CommandProvider shells out once per field. Each of those is a PowerShell start-up, and the fan-out across the command table dominates the time to first presence. Reading the same values from the registry costs a few milliseconds and needs nothing installed.
Adds fetchers under fetch_cord/native/Windows/ for os, kernel, cpu, motherboard, host and mem, alongside the existing packages one. Each returns exactly what its PowerShell command returned, so the values stay interchangeable:
os Microsoft Windows 11 Pro (Win32_OperatingSystem.Caption)
kernel 10.0.26100 (Win32_OperatingSystem.Version)
cpu Intel(R) Core(TM) i7-... (Win32_Processor.Name)
motherboard ASUSTeK COMPUTER INC. (Win32_BaseBoard.Manufacturer)
host PRIME B760-PLUS D4 (Win32_BaseBoard.Product)
mem 12.40 GB / 31.92 GB (same format as the command)
Providers are now ordered native, fastfetch, commands on every platform. That is safe because a native fetcher returns None when it is not confident rather than guessing - an unreadable registry key, or firmware boilerplate like "To Be Filled By O.E.M." - so Fetch.snapshot's existing gap-filling hands the field straight to fastfetch. Native coverage can then grow one field at a time without any platform losing detail it has today. Nothing changes on Linux or macOS, where no native fetchers exist yet.
Two details worth knowing:
Also fixes native fetch() stringifying None into the literal "None", which was harmless while packages was the only fetcher.
Tests fake the registry at the fetcher boundary, so all of them run on a non-Windows CI runner. One asserts the native path makes no subprocess calls, keeping "this adds no dependencies" verifiable rather than a claim.