Avoid outputting Rosetta 2 caveats on Intel machines

[giapoldo]

Verification

• [X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Check for system type (Intel or Silicon) to filter which Caveats are shown. I'm on an Intel mac and I get the following Caveat:

"{cask} is built for Intel macOS and so requires Rosetta 2 to be installed. You can install Rosetta 2 with: softwareupdate --install-rosetta --agree-to-license Note that it is very difficult to remove Rosetta 2 once it is installed."

This particular time it was for the "session" cask, but I have gotten it for other installs too.

What is the motivation for the feature?

This caveat is a warning that is simply unnecessary for Intel systems.

How will the feature be relevant to at least 90% of Homebrew users?

Less visual clutter and cleaner user experience. The first time I got it I had to investigate a little bit as to why I was getting this warning since I am on an Intel system and I had no clue what "Rosetta 2" was, nor did it imply anything about the warning being only for Silicon systems. My first though was that something in my system was misconfigured since the warning showed up.

What alternatives to the feature have been considered?

An alternative is to modify the caveat text to:

"For Apple Silicon systems: {cask} is built for Intel macOS and so requires Rosetta 2 to be installed. You can install Rosetta 2 with: softwareupdate --install-rosetta --agree-to-license Note that it is very difficult to remove Rosetta 2 once it is installed."

[apainintheneck]

It looks like there is already a check that should ensure that this only gets displayed on arm machines.

https://github.com/Homebrew/brew/blob/29c22e0ab3fd9826cefd4b14c143266dea3bc391/Library/Homebrew/cask/dsl/caveats.rb#L143-L152

Could you run the following diagnostic commands locally and post the output here?

brew doctor

brew config

brew ruby -e 'p Homebrew::SimulateSystem.current_arch'

[apainintheneck]

Actually, I figured this out. It's based on pre-computing the caveats when serializing ~formula~ casks for the API.

From the JSON API:

$ brew info Sleipnir
==> sleipnir: 4.6.6
https://www.fenrir-inc.com/jp/sleipnir/
Not installed
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/s/sleipnir.rb
==> Name
Sleipnir
==> Description
Web browser
==> Artifacts
Sleipnir.app (App)
==> Caveats
sleipnir is built for Intel macOS and so requires Rosetta 2 to be installed.
You can install Rosetta 2 with:
  softwareupdate --install-rosetta --agree-to-license
Note that it is very difficult to remove Rosetta 2 once it is installed.

From the Ruby cask:

$ HOMEBREW_NO_INSTALL_FROM_API=true brew info Sleipnir
==> sleipnir: 4.6.6
https://www.fenrir-inc.com/jp/sleipnir/
Not installed
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/s/sleipnir.rb
==> Name
Sleipnir
==> Description
Web browser
==> Artifacts
Sleipnir.app (App)

It seems like this issue is already covered by https://github.com/Homebrew/brew/issues/17288 so maybe we can close this one.

[Bo98]

Yeah Ruby logic in caveats is not supported, and even if it theoretically were we would still avoid them wherever possible for speed reasons. If it were just a few casks then maybe. But not 1.1k casks.

The proper fix here instead of #17288 would be for us to provide better serialisation of "built-in caveats" or alternatively get rid of the Rosetta caveat in favour of a requires_rosetta true DSL (like auto_updates) or similar. In either case, brew could then add the template text to the caveats dynamically.

Formulae already have a similar notion of depends_on arch: :x86_64. I think it would make sense for casks to have a similar pre-install check - instead of a caveat saying you need Rosetta, we have a Requirement that actually checks if you have Rosetta.

[Bo98]

Above point still applies but reading this again:

It's based on pre-computing the caveats when serializing formula for the API.

Why does it not differ in variations? That would be the quick fix here (though could bloat the JSON a little bit).

[apainintheneck]

Above point still applies but reading this again:

It's based on pre-computing the caveats when serializing formula for the API.

Why does it not differ in variations? That would be the quick fix here (though could bloat the JSON a little bit).

My bad I wrote formula above but this is a cask-only issue.

https://github.com/Homebrew/brew/blob/916044581862c32fc2365e8e9ff0b1507a98925e/Library/Homebrew/cask/cask.rb#L458

What's happening here is that we only calculate variations if the cask has on system blocks which isn't the case here.

It looks like there are 1227 casks in the main cask repo that have requires_rosetta set in the caveats section so I'd be a bit worried about it bloating the JSON size but I haven't tested the size locally.

[apainintheneck]

Making Rosetta a requirement for installing these casks on arm machines makes sense to me too assuming it's a straightforward change.

[giapoldo]

It looks like there is already a check that should ensure that this only gets displayed on arm machines.

https://github.com/Homebrew/brew/blob/29c22e0ab3fd9826cefd4b14c143266dea3bc391/Library/Homebrew/cask/dsl/caveats.rb#L143-L152

Could you run the following diagnostic commands locally and post the output here?

brew doctor

brew config

brew ruby -e 'p Homebrew::SimulateSystem.current_arch'

Thanks everyone for taking the time to check this. I'm guessing from the discusssion that I don't need to run the diagnostic commands anymore.

What you're discussing is absolutely out of my knowledge, but don't hesitate to tag me if in need of testers for this.

Thanks a lot again. (Hopefuly I didn't open a pandora's box :P)

[MikeMcQuaid]

@garvamel all good, thanks for the helpful issue!

[MikeMcQuaid]

It looks like there are 1227 casks in the main cask repo that have requires_rosetta set in the caveats section so I'd be a bit worried about it bloating the JSON size but I haven't tested the size locally.

We should prioritise correctness over JSON size. I think having something like caveats_rosetta: true or another minimal addition rather than duplicating the text would make the most sense here.

[EricFromCanada]

Formulae already have a similar notion of depends_on arch: :x86_64

Casks do as well, for example amd-power-gadget.

One solution might be to add :rosetta or :x86_64_or_rosetta as a possible value for depends_on arch: to mean "runs on x86_64 or on ARM with translation installed", which leaves depends_on arch: :x86_64 to mean "requires x86_64 hardware", as is the case above.

[carlocab]

Are there any instances of depends_on arch: :x86_64 that won't work on Rosetta? If not, then we could probably just infer the Rosetta requirement from depends_on arch: :x86_64.

[EricFromCanada]

Probably only casks that tap directly into the hardware like amd-power-gadget, cuda-z, turbo-boost-switcher, and their ilk. (They might be rare enough to not worry about special-casing them.)

[MikeMcQuaid]

@EricFromCanada in those cases if we did what Carlo said: would we be printing the warning unnecessarily or not printing it when we should?

[EricFromCanada]

If depends_on arch: :x86_64 were to mean "runs on x86_64 or on ARM with Rosetta installed", then the Rosetta message would never be shown on x86_64 machines and always be shown on Rosetta-free ARM machines, as it should. The only risk there is with the few cases where the message implies that having Rosetta installed would allow the app to run, but in fact it still wouldn't run because it needs actual x86_64 hardware, rather than just machine translation.

[giapoldo]

If depends_on arch: :x86_64 were to mean "runs on x86_64 or on ARM with Rosetta installed", then the Rosetta message would never be shown on x86_64 machines and always be shown on Rosetta-free ARM machines, as it should. The only risk there is with the few cases where the message implies that having Rosetta installed would allow the app to run, but in fact it still wouldn't run because it needs actual x86_64 hardware, rather than just machine translation.

I think checking for specific hardware for apps is outside of the scope of what brew needs to check and warn for. This is because as a user you don't come to know of a formula or cask you are choosing to install, by searching in brew first instead of a search engine. If there are any doubts users brew info it to make sure. It's because of this "workflow" that I was confused about the Rosetta warning, since the cask I was installing was supposed to be a clean install with no caveats.

The only edge case I can imagine is that one of these apps that need actual hardware were a dependency not obvious to the user.

[Next-Door-Tech]

To clarify, I shouldn't open a separate bug report ticket (as opposed to this feature request) regarding the fact that the next if Homebrew::SimulateSystem.current_arch != :arm line does not disable the Rosetta 2 caveat on Intel Macs, correct?

https://github.com/Homebrew/brew/blob/29c22e0ab3fd9826cefd4b14c143266dea3bc391/Library/Homebrew/cask/dsl/caveats.rb#L143-L152

[MikeMcQuaid]

CC @Rylan12 as this is another example of a new field that we might need for JSON API.

[pauliesnug]

BTW: Is this still a help wanted issue?

[Rylan12]

@pauliesnug, feel free to open a PR!

[botantony]

I think the same issue applies to other builtin caveats that perform a check, f.e. files_in_usr_local:

https://github.com/Homebrew/brew/blob/0a7a60f50645c532528b2dcffbc9b7788cb2dcbb/Library/Homebrew/cask/dsl/caveats.rb#L111-L119

This message will be shown regardless of HOMEBREW_PREFIX. I think it would be better to store builtin caveats in JSON as symbols and evaluate them during installation time (just like deprecation_reason/disable_reason) but there may be problems when more complex caveats message is used, like

caveats do
  requires_rosetta
  <<~EOS
    Please see https://example.com for information regarding application end of life.
  EOS
end

or

caveats do
  requires_rosetta
  reboot
end

or even

caveats do
  requires_rosetta
  reboot
  <<~EOS
    Please see https://example.com for information regarding application end of life.
  EOS
end

Maybe caveats JSON field should be an array of strings instead

[MikeMcQuaid]

I think the same issue applies to other builtin caveats that perform a check, f.e. files_in_usr_local:

@botantony yes, it will 👍🏻

I think it would be better to store builtin caveats in JSON as symbols and evaluate them during installation time (just like deprecation_reason/disable_reason)

Yes, they will need pulled outside the caveats JSON definition into new fields instead that can be evaluated and printed at caveats time per-machine.