feat: allow linux binaries in casks

[SMillerDev]

• 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?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

That was actually easier than expected.

TODO:

• Add --zap support for Linux

TODO in the future:

• Fix macOS casks showing in search on linux
• API support
• Remove OnSystem::MacOSOnly

[SMillerDev]

Okay, as far as I can tell from https://sorbet.org/docs/class-of this should work since NeverSudoSystemCommand is a child of SystemCommand.

I'm also fine removing the types, but that seems counterproductive.

[Rylan12]

In order to generate the linux variations in the API, I believe you'll need to update the #each loop in to_hash_with_variations for casks. This line:

brew/Library/Homebrew/cask/cask.rb

Line 464 in 55f399c

MacOSVersion::SYMBOLS.keys.product(OnSystem::ARCH_OPTIONS).each do |os, arch|

should become something like this (copied from the formula equivalent):

brew/Library/Homebrew/formula.rb

Line 2663 in 55f399c

OnSystem::ALL_OS_ARCH_COMBINATIONS.each do |os, arch|

This may cause problems until on_linux/on_macos blocks have been added to homebrew/cask since that change would cause API generation task to load every cask as Linux, so this might be something for the future.

[SMillerDev]

I'm planning to finish this up without API support, make some casks compatible and then do the API and the removal of the MacOSVersion logic.

[apainintheneck]

That sounds fine.

[SMillerDev]

One more thing to keep in mind before we make this widely available, and I'd like @MikeMcQuaid to weigh in on that one:

What do we want to do with existing casks? Mark all of binary-only casks as depends_on :macos? Or should we somehow have a DSL that marks them as linux-compatible?

[p-linnane]

I think we should add depends_on :macos to existing casks. That would match how we do it in Homebrew/core.

[MikeMcQuaid]

What do we want to do with existing casks? Mark all of binary-only casks as depends_on :macos? Or should we somehow have a DSL that marks them as linux-compatible?

What does binary-only or "allow Linux binaries" mean in the context of this PR, I'm a bit confused. What casks are expected to work or not work after this is merged?

[SMillerDev]

After this PR, casks that only have binary or zap will be installable on Linux*. Obviously most of the casks that meet those criteria would be binaries that only work on macOS. So we need some way to prevent that.

• they are installable only if you don't use the API and explicitly pass --cask

[MikeMcQuaid]

Looks good thanks! Couple of final bits.

[MikeMcQuaid]

Does this imply linux x86_64? Given linux arm will be coming in the near future: what do you invisage doing there? linux_intel or something may make more sense

[SMillerDev]

I considered this, but it feels weird:

sha256 macos:
         arm: "abc"
       intel: "def"

[MikeMcQuaid]

feel like having some Linux-specific makes more sense until the majority of casks support Linux

[MikeMcQuaid]

Would be nice to use a linux: nil state here to infer "this cask does not support Linux", at least in certain cases, rather than needing thousands of depends_on :macos CC @p-linnane for thoughts

[SMillerDev]

The problem is that if you use an on_linux block this assumption breaks

[MikeMcQuaid]

@SMillerDev could be if neither of those are used.

[SMillerDev]

I think I'll need @Rylan12 to help me with that one. Will probably be somewhere during FOSDEM.