Opt-in support for installing casks without the Xcode Command Line Tools

[milanvarady]

Verification

• 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

Add an opt-in environment variable (name up to the maintainers, for example HOMEBREW_NO_DEVELOPER_TOOLS) that lets cask commands run on a Mac without the Xcode Command Line Tools, without failing and without opening the "install command line developer tools" system dialog.

Casks are prebuilt applications, so a compiler is not needed to download and place them. On Apple Silicon, several code paths still reach for the CLT during cask install and uninstall:

• extend/os/mac/diagnostic.rb adds check_for_installed_developer_tools to fatal_preinstall_checks when Hardware::CPU.arm?, so brew install --cask aborts with "No developer tools installed" (via cask/installer.rb perform_preinstall_checks_once).
• cask/quarantine.rb runs /usr/bin/xcrun -find swift to find the Swift helper for the quarantine attribute. Without the CLT that stub opens the installer dialog, and there is no non-Swift fallback, so the cask ends up unquarantined regardless.
• cask/utils/trash.rb runs cask/utils/trash.swift (a #!/usr/bin/swift script) for trash: directives on uninstall and zap.
• DevelopmentTools.locate (mac) falls back to /usr/bin/xcrun -find <tool>, which can open the same dialog.

When the variable is set, each path would take the no-tools route: skip the fatal dev-tools check, skip the xcrun -find fallback in locate, treat Swift as unavailable so quarantine is skipped, trash by moving to the Trash directly, and let the git shim skip its xcrun -find git fallback. Default behavior does not change.

There is a precedent in brew.sh, which already avoids calling xcrun when the tools are absent, with a comment that doing so "opens the install developer tools dialog." This makes the cask paths consistent with that.

What is the motivation for the feature?

I maintain Applite, a GUI app that installs Homebrew casks for non-technical users. It ships its own Homebrew and drives it for installs and uninstalls. Asking these users to download the multi gigabyte Command Line Tools before they can install a single prebuilt app is a large barrier, and today they either get a hard failure on Apple Silicon or an unexpected system dialog asking them to install developer tools.

More generally, any tool, script, or CI job that installs casks on a machine without the CLT hits the same friction, even though the compiler is not needed for the download and move case.

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

Honest answer: as an opt-in variable it will only be set by users and tools that specifically want cask installs without the CLT, so it is not something 90% of users would turn on. What is relevant to everyone is the behavior it corrects. Any macOS user who has not installed the CLT yet (a fresh machine, someone who declined the prompt, an automated setup) can currently hit a surprise developer-tools dialog or a hard failure when a cask is installed on their behalf, even though nothing is being compiled. The change removes that surprise for that case and stays invisible and zero cost to everyone who has the tools, since it is off by default. If the 90% bar is strict here, I understand this may fit better as a documented opt-in for the cask-without-CLT case rather than a default change, and I am happy to take direction.

What alternatives to the feature have been considered?

• Requiring the CLT up front. This is the current situation and the barrier we are trying to remove for prebuilt apps.
• Patching Homebrew's source in a shipped copy. This works but is fragile, since it has to be reapplied on every update and can break silently when internals move.
• Reimplementing cask install natively. Not viable for full parity, because casks can run arbitrary Ruby in preflight and postflight blocks that is not in the JSON API and cannot be reproduced without a Ruby interpreter.

The opt-in variable is the smallest change that covers all the cask paths in one place without affecting default behavior.

[MikeMcQuaid]

Hey @milanvarady. Firstly, thanks for creating a nice open-source tool like this where you give full credit to Homebrew. It's appreciated! Note we are planning on shipping our own GUI (https://github.com/Homebrew/brewui) in the near future but it seems we're targeting slightly different use-cases so I think there's room for both to exist.

Instead of an opt-in, if possible I think we should just make this behaviour instead not require these checks unless they are actually required e.g. a cask depends on a formula. That's my high-level thoughts without actually digging into the code, though; I'll need to verify that we don't have some dependencies that do actually require this.

[milanvarady]

@MikeMcQuaid thanks, that means a lot, and congrats on brewui, I did not know it was in the works. Happy for both to exist.

Making it the default, scoped to when the tools are actually needed, sounds better than an opt-in to me, so I am on board with that direction.

One thing worth flagging from when I traced this, in case it helps your verification. The fatal dev-tools preinstall check is only one of a few places that reach for the tools during a cask's lifecycle, and the others are not tied to whether a cask depends on a formula. They run for every cask:

• cask/quarantine.rb runs /usr/bin/xcrun -find swift to find the Swift helper for the quarantine attribute (install).
• cask/utils/trash.rb runs the trash.swift helper for trash: directives (uninstall and zap).
• DevelopmentTools.locate (mac) falls back to /usr/bin/xcrun -find <tool>.

So scoping the preinstall check to formula-dependent casks would fix the hard failure, but the quarantine and trash steps would still open the dialog on a machine without the tools. brew.sh already guards its own xcrun call for that exact reason, so the same guard on these spots would keep them consistent.

I am happy to open a PR for whichever shape you prefer, or to just share the full list of spots I found if you would rather implement it yourselves. Whatever is least work for you.

[carlocab]

I think #22377 should allow us to do quarantine without a CLT install. It is likely possible to reimplement trash.swift using FFI too.

[MikeMcQuaid]

Thanks @carlocab. Yeh, that's the major blocker I also spotted so far. Trash doesn't really matter too much, quarantine definitely does and blocks even an optional opt-out.

[MikeMcQuaid]

#23043 will do most of this but will need HOMEBREW_DEVELOPER set until it's fully rolled out. When it is, it'll work by default without an opt-in.

This (plus Codex 5.6) encouraged me to finally pick up Homebrew/ruby-macho#997 which should also be nice as we won't need CLT when pouring bottles any more either 😁