Will uninstaller like AppTrap or AppZapper still work with brew cask ?

[luzpaz]

When an application is installed in addition to being copied locally it also writes a .plist to the /Library/ and embeds files in other different locations. Un-installers like the ones mentioned make note of that and when said application is uninstalled the uninstaller is invoked (like apptrap) to clean up any remnants. How does homebrew-cask address this?

[rolandwalker]

Hi!

We don't address this directly. We currently supply an uninstall stanza for some Casks, but it doesn't (yet) touch the user's ~/Library area.

Any research on how AppZapper interacts with install via homebrew-cask would be very welcomed.

If there are any changes we need to make to interact more smoothly with AppZapper, we would be happy to work on that.

[luzpaz]

Currently researching

• a stackover page on this topic
• plutil command
• lsbom command
• How AppTrap works. For example, it runs in the background and when ever an application in uninstalled it get triggered and asks you if you want to keep or trash any remnants left behind by the application. See screenshot

[rolandwalker]

dtrace is also good to know.

[luzpaz]

@rolandwalker
Question from the AppTrap dev:
"Does Cask uninstall apps by moving them to the trash? I couldn't tell from the docs on the github site. AppTrap works by monitoring the trash folder for application bundles that are placed there."

[luzpaz]

FYI: I think the apptrap dev is @kvijayan
If so, @kvijayan hope it's ok with you, it may be easier if this conversation happens here?

[rolandwalker]

Hi!

Currently homebrew-cask just deletes. If there is a technical advantage to using the Trash we could certainly consider it. Truthfully, we are better at installing than un-installing -- at this alpha stage -- and very much still working on it.

Moving an App to the Trash is straightforward; uninstalling a pkg is a little more tricky. You can't be sure that the pkg owns every file under some parent dir until you have walked the whole tree.

If there is an interface for us to communicate with AppTrap directly, we'd also consider that. We currently maintain special cases to work smoothly with Alfred.

[luzpaz]

Hey @rolandwalker
Thanks for you reply :)
Restating my intention to start this conversation is getting homebrew-cask to uninstall whatever the binary file/.pkg/.dmg installs at initiation. This means files like .plist's and perhaps licensure files, system files (of course deleting some of these files depends on the permission level they were installed in). So at the least Homebrew-cask could generate a list of files (for the user) that were installed by the application/package. Letting the user know what options they have and to use their discretion on what to yay or ney. Does that make sense and is it a reasonable request?

Thanks again for your attention and time :)

[kvijayan]

Hello everyone.

Adding cask support to AppTrap shouldn't be difficult. I'm definitely open to it. It's really just a matter of the interface between AppTrap and homebrew-cask. The implementation that would be simplest for me would be to add an observer for a distributed notification from NSDistributedNotificationCenter. However, I believe that would require that homebrew-cask use the ruby cocoa bridge. Anyway, I'm open to ideas. :)

[rolandwalker]

@luzpaz There are 2 types of file; both are reasonable to want to control:

1. the files that the dmg/pkg/whatever creates at install time
2. various app-dependent files created when you run the app

AppTrap specializes in (2). We are still working on (1) but would not mind to help out with (2) if we can.

The current state of homebrew-cask on (1) is mixed. The code is quite good at installing, but when it comes to un-installing, it is dependent on the particular Cask definition as to how well it can un-install. homebrew-cask doesn't (yet) keep its own record of all the files that were installed.

This is an active area of development. See #3066 , which is a start on the "bookkeeping" we need in order to do accurate uninstalls, upgrades etc.

As to obtaining a listing: currently, if the installation is a plain App, not a pkg, you can execute eg brew cask list dropbox to get a summary of the files installed by brew cask install.

It's not perfect. After we merge #3066 and various other fundamental "building blocks", we can give the user more information and more control -- which we very much want to do.

[rolandwalker]

@kvijayan thanks! I'll look into it.

[luzpaz]

@rolandwalker
Sorry to reply late. Thanks for the detailed explanation. It's great to hear where homebrew-cask is going and it's intentions. I don't know of how much help I can be since I don't know much about ruby. I will keep my eyes open to see what I can help with. You can also connect with me via my github account if you think I can be of some assistance in this process.

@kvijayan thanks so much for your effort to post here and share + making AppTrap. 👍

[vitorgalvao]

There’s zap functionality since 0.42.0.