flox: update zap stanza

[tomberek]

Move full uninstallation script to "zap".

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Also bump to 1.0.7 (edit: merged elsewhere)

[razvanazamfirei]

What happens if we run brew uninstall flox? Which files remain?

[tomberek]

What happens if we run brew uninstall flox? Which files remain?

Still working on this and open to any ideas. The thought is that the Nix Store remains. Removing it and then downloading various portions is possible, just slow, duplicative, and frustrating for users. It also means that the history of older generations might not be recoverable either.

It's a bit like Anaconda (https://github.com/Homebrew/homebrew-cask/blob/d63d8b045ea5f4f96b7c6ceb793d96fa652fb433/Casks/m/miniconda.rb), where much of the content is only removed with zap.

[tomberek]

Updated with a bump to 1.0.7.

Updated to transform a brew uninstall flox to leave a functioning daemon-less Store behind. This can then be adopted by a subsequent brew install flox. This makes brew upgrade flox function as expected without removal of the cache.

[krehel]

Hey Tom, nice to see you again! 👋

Trying to figure out how we should approach this one. Probably too much logic in the Caskfile that should be shunted to the package. I’m not deep into this but: is there a reason these postflight commands can’t be run as part of your installer / uninstall package?

For the zap: it would be more amenable to print something to the user to action as a final cleanup step. Again: is there any part of this can that be moved to your package, and leave some minimal more destructive cleanup action to the zap or to the user to run manually?

[tomberek]

Hey Tom, nice to see you again! 👋

👋

Trying to figure out how we should approach this one. Probably too much logic in the Caskfile that should be shunted to the package. I’m not deep into this but: is there a reason these postflight commands can’t be run as part of your installer / uninstall package?

The *flight commands are specifics for brew support; therefore I'd prefer it to retain locality with the Cask. We don't want these run for a non-brew .pkg install because things like upgrade instructions and upgrade behavior is different.

We are also supporting .pkg install/uninstall. So an option would be to have two separate uninstall scripts, one for .pkg and one for brew. That was my first approach, but the uninstall script ended up getting uninstalled itself during brew uninstall flox, making it unavailable for a subsequent zap operation. I ended up inlining the un-installation into the cask as a workaround. Can this be solved with a pkgutil exception or another idiomatic mechanism?

For the zap: it would be more amenable to print something to the user to action as a final cleanup step. Again: is there any part of this can that be moved to your package, and leave some minimal more destructive cleanup action to the zap or to the user to run manually?

There are a few steps needed for zap: so something like brew uninstall --zap --force flox should be a nice way to run the relevant cleanup, even if you happen to be in an intermediate state. Is there a way to reference an uninstallation script in a package that can run even if someone has already done an uninstall?

[tomberek]

@krehel I've updated the method to be cleaner and remove the postflight stanzas. There is some more cleanup we can do after 1.1.0 is out as well, but I'd like to have the auto-bump system have a chance to work.

[stahnma]

Note the 1.0.7 bump was handled in another PR, but I can't edit @tomberek's description.

[stahnma]

Do we need to do something to get this re-reviewed? /cc @krehel @razvanazamfirei

[tomberek]

Simplified and rebase'd.

[p-linnane]

Sorry, going to pass on this. I'm not comfortable adding an entire script inline.