Allow GUI un/installs

[vitorgalvao]

Introduction:

Since the inception of Homebrew-Cask, we mostly (some have slipped through on occasion, and some are still present, even) haven’t allowed casks to call GUIs when installing and uninstalling, in the name of automation.

However, in some cases it actually prevents desirable automation: not auto-opening installer manual: targets and not using tool-provided uninstallers come to mind.

I postulate most users would actually prefer these GUI actions to be called automatically in most cases, the most notable exception being when reinstalling a system (since a bunch of casks are installed).

It also seems more in line with the goal of #13201 of making our automation as close to the manual installation as possible.

---

Proposal:

Change policy and start allowing GUIs to be called, but only allow GUIs as the last resort.

When calling a GUI is necessary for an action, allow the user to pick if a GUI will be called or the action will be interrupted. Make not allowing GUIs the default, for backwards compatibility.

Implement --allow-gui as a flag to be given at runtime or in HOMEBREW_CASK_OPTS. It means “If this action needs a GUI, run it; if not, output a warning on how to proceed manually” (i.e. the same instructions we have now).

Rename installer manual: to installer gui:.

Add uninstall gui:. It runs in addition to the other flags, and before them (otherwise it could very well be removed by them).

When we call install/uninstall and the corresponding installer gui: or uninstall gui: exists, check if --allow-gui is set and act accordingly.

When opening GUIs, do so with open -W. This way the command will be blocked until it finishes, preventing a barrage of GUIs left open when installing multiple apps and allowing for && and other subsequent commands.

brew cask info should inform if install/uninstall needs a GUI.

---

Checklist:

• [ ] Add --allow-gui flag.
• [ ] Rename (and update implementation of) installer manual:.
• [ ] Implement uninstall gui:.
• [ ] Update implementation of info.
• [ ] Update documentation.
• [ ] Add tests.
• [ ] Replace installer manual: with installer gui: in casks.
• [ ] Add uninstall gui: to adobe-creative-cloud.
• [ ] Add uninstall gui: to little-snitch.
• [ ] Add uninstall gui: to teamviewer.
• [ ] Add uninstall gui: to teamviewer-host.

Pinging @caskroom/maintainers, but any user is welcome to chime in.

[reitermarkus]

We don't need *_calls_gui, because with installer/uninstall gui:, we already know this.

[vitorgalvao]

We don't need *_calls_gui, because with installer/uninstall gui:, we already know this.

Good point, completely missed that, as the ideas to rename and add gui: came when I was already writing. Amended the post.

[mwean]

I think this is a great direction 👍

[numbermaniac]

Perhaps a note should be added to the relevant brew cask info cask if the installation requires a GUI?

[vitorgalvao]

@Numbermaniac Agreed. Updated the top post.

[jawshooah]

I'm fine with this as long as we aren't blocking on the GUI installer. Otherwise we'll break automated install scripts.

[vitorgalvao]

Otherwise we'll break automated install scripts.

How so? That’s what --no-gui is for.

If you say we should --yes-gui instead, at least at first (giving a warning about the reversal), I can agree, but being completely non-blocking on GUI installs sounds like a bad idea to me, especially when installing multiple apps. When installing multiple apps I don’t want a ton of GUIs to suddenly flood the screen. Also, making it non-blocking makes scripting less useful, since we can’t rely on the installation being finished before continuing. As an example, imagine an automated script that installs the cask and then reboots. If it’s not blocking, nothing will be installed (just downloaded) and the system rebooted all the same.

In sum, as I see it, making not calling a GUI the default (either as an adjustment period or ever) is preferable to making GUI installs non-blocking.

[jawshooah]

In sum, as I see it, making not calling a GUI the default (either as an adjustment period or ever) is preferable to making GUI installs non-blocking.

In that case, I'd prefer that we make this an opt-in feature. Many of our users use scripts to automate the installation of many casks at once, usually to bootstrap a new machine. If we change the default behavior to opening GUI installers and blocking on user input, we're violating those users' expectations in a big way, and probably setting ourselves up for a nice influx of "bug" reports.

[vitorgalvao]

Changing the suggestion, then, and updating the top post. Making non-GUI the default, and add a --allow-gui (less ridiculous than --yes-gui). Changing that behaviour to be the reverse is a suggestion for another time (if ever).

[vitorgalvao]

Change from discussion to ready to implement.

[yurikoles]

Does anyone volunteer mentorship on this ticket? I have small xp in Ruby, I'm an iOS Dev by myself with 6 years of xp.

[reitermarkus]

@yurikoles, if you decide to tackle this, we will certainly provide some guidance.

[yurikoles]

@reitermarkus what is the better way to communicate?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[yurikoles]

@reitermarkus I had dropped you an email.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.