Skip to content

Move the 'wsl?' bool from the OS::Linux module up to the OS module#22309

Merged
MikeMcQuaid merged 1 commit into
Homebrew:mainfrom
lstn:move_wsl_up
May 20, 2026
Merged

Move the 'wsl?' bool from the OS::Linux module up to the OS module#22309
MikeMcQuaid merged 1 commit into
Homebrew:mainfrom
lstn:move_wsl_up

Conversation

@lstn
Copy link
Copy Markdown
Contributor

@lstn lstn commented May 17, 2026

This PR moves the makes the internal wsl? boolean member of Homebrew's OS::Linux available directly in as a public member of OS in os.rb alongside OS.mac? and OS.linux?
While I've modified the handful of references in the code to point to this new location, I've maintained backwards compatibility by having leaving the definition of wsl? in OS::Linux but changing it to return the value of OS.wsl? instead which should prevent any breakage for users that happened to be using OS::Linux.wsl? in, for instance, brewfiles.

Why this change?

I ran into some issues with Brewfiles, which I only have one of however, one that covers 10+ machines and depends on conditionals. The Brew, brew Bundle and Brewfile "Advanced brewfiles" section seems to encourage this usage of brewfiles, and explicitly provides examples of conditionals using OS.mac? and OS.linux?.

It's however not possible to safely check OS::Linux.wsl? to see if we are on a WSL machine since the OS::Linux module is only loaded by brew if we are currently on a Linux machine (here), thus, if we happen to be on a Mac (or run with HOMEBREW_TEST_GENERIC_OS=true), we get:

# Brewfile excerpt
...
brew "mypackage" unless OS::Linux.wsl?
...

# shell prompt, on a macOS machine
❯ brew bundle 
Error: Invalid Brewfile: undefined method 'wsl?' for module OS::Linux

Of course, we could get around this by using compounded conditional statements/checking we are on Linux first and THEN checking for WSL which would prevent the exception being raised, but IMO that leads to a more complicated to read/understand brewfile.

Hope you'll consider this change or propose an alternative if this isn't adequate, I'm happy to adjust the PR. thanks.


  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
  • Have you written new tests (excluding integration tests) for your changes? Here's an example.
    • There did not seem to be existing tests for mac? and linux? and the existing test for OS::Linux.wsl? tests this change by virtual of the fact that that reference has been changed to refer to this new wsl? method. I can add an additional test however if you feel it warrants the duplication.
  • Have you successfully run brew lgtm (style, typechecking and tests) with your changes locally?

  • AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes. Non-maintainers may only have one AI-assisted/generated PR open at a time.

@MikeMcQuaid
Copy link
Copy Markdown
Member

Of course, we could get around this by using compounded conditional statements/checking we are on Linux first and THEN checking for WSL which would prevent the exception being raised

I think this makes more sense, sorry.

@lstn
Copy link
Copy Markdown
Contributor Author

lstn commented May 17, 2026

Of course, we could get around this by using compounded conditional statements/checking we are on Linux first and THEN checking for WSL which would prevent the exception being raised

I think this makes more sense, sorry.

@MikeMcQuaid okay, that's a bit disappointing to hear but no problem.

Would you be willing to consider an OS.windows? bool instead?
I know homebrew does not/will not support windows, but I think from a logical point of view such a boolean being true if a user is on WSL or somehow emulating Linux from windows in a different fashion (cygwin/git-bash? i haven't used those in years so I'm not sure if homebrew works with them) makes sense.

brew "mypackage" unless OS::Linux.wsl? if OS.linux? feels quite cumbersome (and also I believe won't install mypackage on mac so it needs additional OR logic to handle that - thus it gets to be quite a long command...)

@MikeMcQuaid
Copy link
Copy Markdown
Member

Use brew "mypackage" if OS.linux? && OS::Linux.wsl?

Would you be willing to consider an OS.windows? bool instead?

No, sorry.

@lstn
Copy link
Copy Markdown
Contributor Author

lstn commented May 18, 2026

brew "mypackage" if OS.linux? && OS::Linux.wsl?

@MikeMcQuaid To clarify, the solution you propose here does the exact opposite of what my example was trying to achieve. I agree it is not cumbersome and it doesn't make things harder to read. However, like I said, that statement works installs mypackage on WSL systems only - the exact opposite of the "raison d'etre" for this PR.

The usecase I was presenting was installing mypackage on any environment except WSL, which is why I was demonstrating an unless statement and not an if - this is what gets cumbersome/complicated in the context of a brewfile.

Without a "top-level", public boolean member of the OS helper module that allows checking for WSL, in order to not raise an exception and install a package on every system except WSL in a safe way, you have to do:

# Install a specific package if we're on any machine except a WSL one

# using if
brew "foobar" if (OS.linux? && !OS::Linux.wsl?) || OS.mac?
# using unless
brew "foobaz" unless (!OS.linux? || (OS.linux? && OS::Linux.wsl?)) && !OS.mac?

Semantically, if you're on the ruby purist side of the scale, and you want to do something everywhere except one place you'd want to use an unless statement, however that unless statement is extremely confusing (I'm confused reading it and I'm the one who wrote it!), so unless you like unmaintainable code you're going to go the non-purist way and use the if, which is still a complicated statement, especially if you intend to repeat it multiple times in your brewfile.

I may also be 100% wrong on this, but from looking at brewfile examples and some of the code, but it seems to me like you may prefer the ruby "poetry" style of writing ruby on a personal level, and the statements above would definitely not be considered poetic anymore as soon as the parentheses are thrown in.

You've made it clear you don't want to implement an alternative here which is OK, it's your software not mine so I'm not entitled to it!
As a result, I may (read: 90% most likely will) go back to relying on Homebrew much, much less as it's the only part of my setup that's not self-written in pure bash and that's OK too - as you said in a different issue (the one about injecting environment variables outside of HOMEBREW_*; incidentally I made this PR to try and solve one of the original cases that the environment injection would've solved), maybe brew and Brewfiles just are not the tools for me.

But I just want to point out that it seems counterintuitive and IMO (huge focus on the "my opinion" part of that acronym, I mean I didn't write the article!) not in line with the philosophy you're presenting in your article Homebrew Bundle, brew bundle and Brewfile, which is what made me decide to introduce Homebrew/Brewfiles into my previously bash-only stack. So it's just a bit disappointing personally (and selflishly) to see that it didn't end up being the tool I thought it would be for me.

@MikeMcQuaid
Copy link
Copy Markdown
Member

Ok, thanks.

Can you explain a bit more why you want to differentiate WSL and Linux in this way?

@lstn
Copy link
Copy Markdown
Contributor Author

lstn commented May 19, 2026

@MikeMcQuaid Because WSL is limited, and with a multi-machine Brewfile, there are things that I would not want on WSL but want on all my other machines, or might even cause environment breakage if they were installed.

The one that was my "immediate need" while I was setting up my Brewfile and is a key part of my home office setup was Synergy, as that would have to be installed on the Windows host itself (since I presume it would do absolutely nothing on a headless linux like WSL). I'm sure there's other examples of similar software, especially anything that deals with keyboard/mouse (xdotool?) manipulation or remote desktops.

Other ones that come to mind immediately: docker, podman, and anything else which runs through HyperV and uses a remote client to connect to the actual tool on WSL rather than the "real" tool directly. These are the ones I was referring to when I said "might even cause breakage" above.

brew "synergy-core" unless OS.wsl?
brew "podman" unless OS.wsl?

Is a lot more palatable than

# with ifs
brew "synergy-core" if (OS.linux? && !OS::Linux.wsl?) || OS.mac?
brew "podman" if (OS.linux? && !OS::Linux.wsl?) || OS.mac?

# with unlesses
brew "synergy-core" unless (!OS.linux? || (OS.linux? && OS::Linux.wsl?)) && !OS.mac?
brew "podman" unless (!OS.linux? || (OS.linux? && OS::Linux.wsl?)) && !OS.mac?

Other things that I could see being a problem (but I don't use myself) would be anything with a graphical component; I know typically those are casked/limited to macOS anyways typically but for any formulas that provide a graphical interface (I don't use many graphical programs so I'm not the right person to ask, maybe there aren't many/any?), the WSLg experience is pretty terrible still so I could see an unless OS.wsl? being used for those too..,

Can you explain a bit more why you want to differentiate WSL and Linux in this way?

It's also not so much about differentiating the two but more about having a clean, safe public api to determine we are on WSL.

@MikeMcQuaid MikeMcQuaid reopened this May 20, 2026
Copy link
Copy Markdown
Member

@MikeMcQuaid MikeMcQuaid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine, let's do this, thanks.

@MikeMcQuaid MikeMcQuaid enabled auto-merge May 20, 2026 07:20
@MikeMcQuaid MikeMcQuaid added this pull request to the merge queue May 20, 2026
Merged via the queue into Homebrew:main with commit ad42b17 May 20, 2026
70 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants