-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
cask uninstall: opt-in quit/signal on upgrade/reinstall #21130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
toobuntu
wants to merge
2
commits into
Homebrew:main
Choose a base branch
from
toobuntu:feature/cask-dsl/quit-signal-on-upgrade
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
11 changes: 11 additions & 0 deletions
11
Library/Homebrew/test/support/fixtures/cask/Casks/with-uninstall-quit-on-upgrade.rb
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| cask "with-uninstall-quit-on-upgrade" do | ||
| version "1.2.3" | ||
| sha256 "8c62a2b791cf5f0da6066a0a4b6e85f62949cd60975da062df44adf887f4370b" | ||
|
|
||
| url "file://#{TEST_FIXTURE_DIR}/cask/MyFancyPkg.zip" | ||
| homepage "https://brew.sh/fancy-pkg" | ||
|
|
||
| pkg "MyFancyPkg/Fancy.pkg" | ||
|
|
||
| uninstall quit: "my.fancy.package.app", quit_on_upgrade: true | ||
| end | ||
14 changes: 14 additions & 0 deletions
14
Library/Homebrew/test/support/fixtures/cask/Casks/with-uninstall-signal-on-upgrade.rb
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| cask "with-uninstall-signal-on-upgrade" do | ||
| version "1.2.3" | ||
| sha256 "8c62a2b791cf5f0da6066a0a4b6e85f62949cd60975da062df44adf887f4370b" | ||
|
|
||
| url "file://#{TEST_FIXTURE_DIR}/cask/MyFancyPkg.zip" | ||
| homepage "https://brew.sh/fancy-pkg" | ||
|
|
||
| pkg "MyFancyPkg/Fancy.pkg" | ||
|
|
||
| uninstall signal: [ | ||
| ["TERM", "my.fancy.package.app"], | ||
| ["KILL", "my.fancy.package.app"], | ||
| ], signal_on_upgrade: true | ||
| end |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having to always write
truehere (and for:signal_on_upgrade) feels redundant, since this should never be anything other thantrue(becausefalseis inferred when the key is omitted).I wonder if there's a nicer/DRYer way to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @carlocab. I agree but can't figure out a perfect option here. Some ideas:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I don't have great suggestions, hence the ✅. I was thinking something like
but not a huge fan of it. I'm fine with
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, both – agreed it's a bit wordy to always write
*_on_upgrade: true.The main reason I went with this approach is that it lets the new behavior piggy‑back on the existing “directive value + boolean metadata” pattern in the uninstall DSL (e.g.,
script: { executable: ..., sudo: true }).quit_on_upgrade: true/signal_on_upgrade: truefollow that convention: the directive value remains the single source of truth for the bundle IDs, and the opt-in boolean just says “also run this during upgrade/reinstall” without adding a new directive name.Keeping them as separate metadata keys lets
AbstractUninstallvalidate them alongside the existing directive keys, and lets the RuboCop cop simply treat them as “keys to ignore for ordering” without introducing a new directive name or a special case path likeuninstall_and_quit.The more generic keys you suggested seem to want either context‑dependent semantics (“what does this mean next to other directives?”) which felt harder to explain in the Cookbook and in code comments, or a new entry point that would be a bigger DSL/implementation change than this PR set out to make. In particular, a form like
uninstall quit_on_upgrade: "..."oruninstall_and_quit "..."would work fine on its own, but it’s then either a full replacement foruninstall quit:(a bigger DSL change, since we now have two ways to direct “quit this app on uninstall-like operations”) or it becomes an upgrade-only directive that tends to duplicate the same bundle IDs in a second place. Keeping the bundle IDs only onquit:and using a small flag to control when it also runs during upgrade/reinstall sidesteps that and keeps the change smaller.If we want to reduce the visual noise a bit, one incremental tweak would be to treat the presence of
quit_on_upgrade/signal_on_upgradeas the opt‑in and not require= trueeverywhere, while keeping the rest of the wiring as is.If there’s consensus that one of the alternative wordings is worth the extra refactor, I’m happy to take guidance and adjust, but my goal here was to keep the opt‑in clearly as metadata, avoid duplicating the bundle IDs, and keep the changes small and local enough to be easy to maintain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @toobuntu! Rethinking from your message and the code, how about:
and
as the behaviour seems to be mutually exclusive (you cannot both quit and signal at once for the same ID on uninstall/reinstall, right?).
if I'm wrong about being exclusive then I think we're back to:
which would affect both quitting and signal if either/both are specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In
Library/Homebrew/cask/artifact/uninstall.rb, theuninstall_phasemethod runs uninstall directives sequentially. Those directive keys are listed inORDERED_DIRECTIVESinLibrary/Homebrew/cask/artifact/abstract_uninstall.rb, and the uninstall logic iterates over those keys in their defined order. Nothing prevents bothquitandsignalfrom running for the same bundle ID, and there are at least 9 casks in homebrew/cask which do use both quit and signal on the same bundle ID—where signal essentially serves as a fallback if quit didn't suffice.Distinguishing quit v. signal in the DSL might be an unnecessary complexity, and a single opt-in for both during upgrade/reinstall is likely sufficient. Intuitively, if a cask should quit on upgrade/reinstall, it seems reasonable that it should also signal.
I had intended the two new keys in this PR to be top-level boolean metadata keys alongside the other uninstall directives (though without enforcing an order on them), to keep the diff minimal.
It seems you envision the opt-in flag nested within the quit/signal directive itself, which is both easier to read and more semantically precise. However, it seems that no existing infrastructure supports such per-directive conditional execution flags (e.g.,
on_upgrade: true,when: "default" | "always" | "upgrade" | "reinstall",on_upgrade_reinstall: true, etc.). Implementing this would seemingly require refactoring the uninstall DSL parsing, runtime execution logic, and linting cops. Among those options, anon_upgrade:boolean seems simpler to implement than the more extensiblewhen:strings which might be unnecessary given the current needs.Given that, I have two key queries for direction:
on_upgrade: true)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing something like
seems ideal here, depending on how much refactoring this really requires.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either this or what @carlocab has proposed above work for me. No strong preference either way.