Native Windows Brew prototype: request for guidance on small upstreamable abstractions

[anubissbe]

Hello Homebrew maintainers,

I am working on a native Windows prototype that tries to preserve Homebrew
concepts while running directly in Windows Terminal and PowerShell. This is not
a WSL bridge, not an MSYS2 runtime identity, and not a wrapper around WinGet,
Scoop, Chocolatey, npm, or wsl.exe.

I am not asking Homebrew to accept native Windows support today. I am asking
whether maintainers would consider a small sequence of no-behavior-change
abstractions that could make a future native Windows experiment reviewable
without disturbing current macOS/Linux behavior.

Prototype repo:

https://github.com/Euraika-Labs/brew-windows

Current release:

https://github.com/Euraika-Labs/brew-windows/releases/tag/v0.2.3

The current public demo path is:

irm https://github.com/Euraika-Labs/brew-windows/releases/latest/download/install.ps1 | iex
brew install codex
codex --version

What exists in the prototype today:

• per-user prefix at %LOCALAPPDATA%\Homebrew;
• PowerShell-native installer and runtime;
• Cellar-style package layout;
• checksum-verified downloads;
• .cmd and .ps1 shims;
• generic package catalog;
• Windows CI for Windows PowerShell and PowerShell 7;
• release payload SHA256 and artifact attestation;
• a real codex package using official OpenAI Windows release assets.

I have read the prior native Windows issue:

Homebrew/brew#14197

The concern about Unix/Bash assumptions is valid. The prototype was built to
gather evidence before asking for any upstream changes.

The proposed first PR sequence would be deliberately narrow:

1. Document and test the launcher-to-brew.sh environment contract.
2. Add inert Windows host detection without enabling Windows support.
3. Extract path-list and executable-resolution helpers while preserving current
   Unix behavior.
4. Extract shellenv rendering so PowerShell output can be added narrowly.
5. Extract keg linking behind a strategy interface before discussing Windows
   shims.

The full dossier and PR sequence are here:

• https://github.com/Euraika-Labs/brew-windows/blob/main/docs/UPSTREAM_DOSSIER.md
• https://github.com/Euraika-Labs/brew-windows/blob/main/docs/UPSTREAM_PR_SEQUENCE.md
• https://github.com/Euraika-Labs/brew-windows/blob/main/docs/UPSTREAM_MAINTAINER_PACKET.md

Questions:

• Is native Windows categorically out of scope for Homebrew?
• If not, which no-behavior-change abstraction would be the least objectionable
  first PR?
• Would any Windows-related code need to stay outside Homebrew/brew until a
  much later milestone?
• Would an unsupported or Tier 3 experimental path still create too much
  maintenance burden?
• Are Windows bottle tags, shim link strategies, or PowerShell shellenv changes
  out of bounds?

I am happy to keep this as a separate prototype if that is the right answer. I
would rather ask early and avoid wasting maintainer review time than open a
large "Windows support" PR.

[p-linnane]

Thanks for the thorough writeup, and for asking before opening a large PR.

Native Windows is firmly out of scope for Homebrew/brew, and Chocolatey, Scoop, or WinGet are better fits. Unlike the Linuxbrew merge, which kept the Unix assumptions almost intact, Windows breaks nearly all of them at once. Even the inert abstractions carry permanent maintenance and test burden for an unsupported target, so we would decline them as Windows enablement. Best kept as an independent project.

[MikeMcQuaid]

Hi @anubissbe. I gently disagree with @p-linnane here: we already have an OS level abstraction layer and Windows is more tolerant of Unix standards than it used to be.

I don't think we'd ever be willing to e.g. replace all Bash/any Ruby with Powershell but we'll consider isolated, well-tested use of the existing extend/os abstraction layer for basic Windows support.

I think what would probably make most sense is for you to "port" Homebrew to Windows entirely yourself first and then start submitting small (sub-500 lines diff) PRs bit-by-bit.

Happy to discuss specifics PRs here. For specific questions:

• Is native Windows categorically out of scope for Homebrew?

Short-term yes, long-term no: particularly if a Windows installer installs Bash, Ruby, Curl, etc.

• If not, which no-behavior-change abstraction would be the least objectionable
  first PR?

Library/Homebrew/os/windows.rb but, as said above, I'd want to see a demonstration than most work has been done already and this is an actual working, useful and usable fork rather than just have us import random files that later get abandoned.

I am happy to discuss the fork in advance to make it easier to ensure you build it in a way that can actually be merged back one day and doesn't diverge too far.

• Would any Windows-related code need to stay outside Homebrew/brew until a
  much later milestone?

Yes. You should have actual CI, binary packages, end-to-end testing and non-you users.

• Would an unsupported or Tier 3 experimental path still create too much
  maintenance burden?

That would be how any "support" would start.

• Are Windows bottle tags, shim link strategies, or PowerShell shellenv changes
  out of bounds?

Not for now for all except extended Powershell support. We already support that as an optional user shell on macOS or Linux.

[MikeMcQuaid]

I've been thinking and playing around with this a bit this morning on my Windows machine and: I think the right thing here/middle-ground is to continue double-down on WSL.

We have WSL-specific logic, it's trivial to install Ubuntu there, the performance overhead is minimal and it's trivial to still interact with Windows-native executables from inside that environment. For example, just to see what it'd look like, I'm playing around with adding winget support to brew bundle; much as we currently already have flatpak support which is Linux-only.

Instead of "porting Homebrew to Windows" I'd instead propose "making Homebrew under WSL better interact with Windows systems".

This seems to match Microsoft's own direction of travel where e.g. Windows Terminal, VS Code etc. have very strong WSL integration out of the box. Homebrew is, after all, a developer tool and that seems to be the most growing "developer environment" on Windows.

[MikeMcQuaid]

I'd instead propose "making Homebrew under WSL better interact with Windows systems".

Some examples from today:

• bundle: add WinGet support brew#22397
• config: show Windows build on WSL brew#22398

[ReenigneArcher]

I'm not a maintainer, but I would really like this to come to fruition. Having a universal package manager that works on all major OSes would greatly simplify c/c++ development.

[anubissbe]

Thanks @MikeMcQuaid and @p-linnane for the steering. Two days on, the architecture you sketched is functioning end-to-end and I wanted to share progress while course corrections are still cheap.

What changed

v1's PowerShell-native reimplementation has been archived. The current v2/ directory uses the shape MikeMcQuaid sketched:

• bash = MinGit's native Win32 bash.exe (no MSYS2 install, no WSL)
• Ruby = RubyInstaller 4.0.5-1 (no DevKit; portable extract)
• curl = the C:\Windows\System32\curl.exe that ships in Windows 10 1803+

A Windows-native launcher (brew.ps1, ~1.1 kLOC) bootstraps these three on first run into %LOCALAPPDATA%\Homebrew\runtime\, then exec's bin/brew against upstream's brew.sh + brew.rb. Upstream Homebrew's execution flow is preserved; the differences from upstream are a set of 20 small patches listed below.

Current state (verified on Windows 11)

brew --version                                # Homebrew >=4.3.0
brew config
brew doctor                                   # only legitimate Tier 3 warnings
brew tap euraika-labs/windows file:///<tap>
brew install euraika-labs/windows/ripgrep     # built in 3 seconds
rg --version                                  # ripgrep 15.1.0
brew list                                     # ripgrep
brew uninstall ripgrep                        # clean reverse

Patch shape

20 patches against a pinned upstream Homebrew commit, indexed in v2/launcher/patches/README.md. Properties of the set:

• Range: 2 LOC to 219 LOC. Smallest is windows-python-rescue.patch (rescue Errno::ENOENT around Language::Python.major_minor_version). Largest is windows-diagnostics.patch (219 LOC; adds Windows-specific brew doctor checks as a new extend/os/windows/diagnostic.rb file). Median is ~20 LOC.
• Guarded. Most use the existing extend/os/<platform>/<module>.rb loader pattern; a handful do an inline RbConfig::CONFIG["host_os"].match?(/mswin|mingw|cygwin/) check. macOS and Linux behavior is preserved in every patch.
• Single concern per patch. Each has a header documenting target, phase, and rationale.

Biggest categories:

• Replacing fork+exec with Process.spawn for code paths that need a child process - windows-system-command, windows-utils-popen, windows-homebrew-system, windows-fork-stub.
• Windows path / extension handling - windows-which-extensions (PATHEXT probe in Kernel#which), windows-path-separator, windows-formulary-drive-path (avoid FromURILoader claiming C:/... paths).
• Tier 3 brew doctor - windows-diagnostics (new Windows checks), windows-doctor-overrides (Windows-aware overrides on existing checks).

Where this sits on your roadmap

Explicitly: this is not ready for upstream PRs. Per your feedback I'm still in the "complete the external port first" phase. Specifically:

• No tagged release yet, so no irm install.ps1 | iex flow. Installation is from-source today.
• No non-author users yet. Recruitment starts once the release pipeline ships.
• One Windows-only formula (ripgrep) exists; the Windows-shaped catalog needs to grow.

So this is a status update rather than a PR request. When non-author users + a public release + CI maturity exist, the smallest patches (probably windows-os-detection.patch, 15 LOC, which adds OS.windows? and an OSTYPE case in brew.sh) would be the conversation candidates.

Repo: Euraika-Labs/brew-windows. Happy to take "this is the wrong direction, stop" feedback while course corrections are still cheap.

[MikeMcQuaid]

Thanks @MikeMcQuaid and @p-linnane for the steering.
You're welcome!

• bash = MinGit's native Win32 bash.exe (no MSYS2 install, no WSL)

Seems good 👍🏻

• Ruby = RubyInstaller 4.0.5-1 (no DevKit; portable extract)

Also seems good although you may want to consider reusing Portable Ruby for this.

• curl = the C:\Windows\System32\curl.exe that ships in Windows 10 1803+

Are you shipping this yourself? I'd just make a hard requirement on that Windows version.

Another big missing requirement here is Git.

Note that it's fine in the interim but you probably need to build all the binaries you need yourself in the longer-term.

A Windows-native launcher (brew.ps1, ~1.1 kLOC) bootstraps these three on first run into %LOCALAPPDATA%\Homebrew\runtime\

Seems fine for now but I'd recommend using something like the macOS .pkg launcher (MSI or NSIS perhaps) to ship all your dependencies.

Current state (verified on Windows 11)

brew --version                                # Homebrew >=4.3.0
brew config
brew doctor                                   # only legitimate Tier 3 warnings
brew tap euraika-labs/windows file:///<tap>
brew install euraika-labs/windows/ripgrep     # built in 3 seconds
rg --version                                  # ripgrep 15.1.0
brew list                                     # ripgrep
brew uninstall ripgrep                        # clean reverse

Patch shape

20 patches against a pinned upstream Homebrew commit, indexed in v2/launcher/patches/README.md.

The patch approach generally makes sense. I'd suggest making sure that brew style passes on these and maintaining a separate branch rebased on top of Homebrew's main.

Properties of the set:

• Guarded. Most use the existing extend/os/<platform>/<module>.rb loader pattern; a handful do an inline RbConfig::CONFIG["host_os"].match?(/mswin|mingw|cygwin/) check.

The latter checks will not be mergeable, they must all use the prior.

• Replacing fork+exec with Process.spawn for code paths that need a child process

Why is this need, out of interest?

• Windows path / extension handling - windows-which-extensions (PATHEXT probe in Kernel#which), windows-path-separator, windows-formulary-drive-path (avoid FromURILoader claiming C:/... paths).

Make sure that these are all 100% required. AI will hallucinate old Windows file and path separator changes that may not be needed on modern versions.

Where this sits on your roadmap

Explicitly: this is not ready for upstream PRs. Per your feedback I'm still in the "complete the external port first" phase. Specifically:

• No tagged release yet, so no irm install.ps1 | iex flow. Installation is from-source today.
• No non-author users yet. Recruitment starts once the release pipeline ships.
• One Windows-only formula (ripgrep) exists; the Windows-shaped catalog needs to grow.

Yes, considerably. https://formulae.brew.sh/analytics/install/30d/ should be a good starting point.

So this is a status update rather than a PR request. When non-author users + a public release + CI maturity exist, the smallest patches (probably windows-os-detection.patch, 15 LOC, which adds OS.windows? and an OSTYPE case in brew.sh) would be the conversation candidates.

Ok, good to know.

Repo: Euraika-Labs/brew-windows. Happy to take "this is the wrong direction, stop" feedback while course corrections are still cheap.

Cannot guarantee that we'll merge any/all of this or that you'll be able to get users but this is the right direction.

I'd suggest setting up a dedicated homebrew-core-windows fork with brew test-bot using Windows GitHub Actions runners etc. sooner rather than later.

Basically: you want to emulate Homebrew itself as closely as possible to make a possible future fork merge as easy as possible.

Nice work and good luck!

[anubissbe]

Cannot guarantee that we'll merge any/all of this or that you'll be able to get users but this is the right direction.

I do understand, and my main goal is at least have it working for myself, as I am used to use brew, and I also want to use it on windows (and I do have fun with writing the code for it)