Tarsnap.app isn't in /Applications

[gperciva]

It looks like brew linkapps is deprecated. I think we need to have a brew "cask" formula to get Tarsnap.app in /Applications instead of hidden away in

/usr/local/Cellar/tarsnap-gui/VERSION/

@ilovezfs, does that sound right?

(I'll work on this after I've fixed the "reload launchd after fixing the binary path" problem.)

[shawwn]

I wrote a brew cask formula that should fix this: https://github.com/shawwn/homebrew-cask/blob/tarsnap/Casks/tarsnap.rb

(Be sure to change /shawwn/ to /Tarsnap/, of course.)

It puts tarsnap-gui on the command line, just like tarsnap. And it runs tarsnap-gui-postinstall after installation, which ensures the plist is copied to ~/Library/LaunchAgents/ correctly.

[gperciva]

Thanks, this is a great start!

I'm a little bit leery about the number of new features in the cask and your 1.0.3:

• I see that you called it tarsnap instead of tarsnap-gui. I'd rather keep the GUI called tarsnap-gui if possible. Was this change prompted so that the conflicts_with formula: 'tarsnap-gui' line would work? I'm not familiar with how brew and brew cask interact.

• this version defaults to having scheduling enabled with the tarsnap-gui-postinstall script. I'd rather not make assumptions about that -- for now, users can enable scheduling in the Setting screen if they want it.

• on a related note, I'd rather avoid using extra shell scripts. Tarsnap's tagline is "... for the truly paranoid", after all! It's easy for users to see what's happening in:

  test do
  system "#{opt_prefix}/Tarsnap.app/Contents/MacOS/Tarsnap", "--version"
  system "#{opt_prefix}/Tarsnap.app/Contents/MacOS/Tarsnap", "--check"
  end
  

  If we call a -postinstall script, they need to go hunting down the app source to see what will be done.
  (Granted, we could theoretically add nasty stuff to the C++ code, so avoiding the extra shell script is hardly a guarantee that everything is fine.)

• why did you add a build-osx.sh? What does it fix that the non-cask TarsnapGui's install section does?

• what's the bin/tarsnap-gui script for?

In many (or all) of these cases, adding 1-3 sentences of comments (either to the files themselves, or the git commit messages) would clear things up.

For now, I'm going to go ahead and announce a beta-test of 1.0.2 on the tarsnap-users mailing list as that adds the --check option. Once that's gone through a week of possible objections, I'll make that official. At that point, I'd like to add --check to the regular brew formula and/or move to a brew cask formula based on that 1.0.2.

[shawwn]

I see that you called it tarsnap instead of tarsnap-gui. I'd rather keep the GUI called tarsnap-gui if possible. Was this change prompted so that the conflicts_with formula: 'tarsnap-gui' line would work? I'm not familiar with how brew and brew cask interact.

That's fine. There wasn't any reason for the name change other than convention. And it might be simpler to migrate to Cask with identical names; I'm not sure.

this version defaults to having scheduling enabled with the tarsnap-gui-postinstall script. I'd rather not make assumptions about that -- for now, users can enable scheduling in the Setting screen if they want it.

For consistency, the UI elements related to scheduling should probably be disabled if the user hasn't enabled it yet. But I don't think active users would mind having it enabled.

One way it could work: If a user tries to change a job's schedule from Disabled to something else, it could run tarsnap-gui-postinstall at that point. That way it's automatic, and it ensures it won't annoy users who are just "window shopping" (i.e. curious about the program, but not committing themselves to using it yet).

on a related note, I'd rather avoid using extra shell scripts. Tarsnap's tagline is "... for the truly paranoid", after all!

That's a good point, but consider that each Tarsnap.app will be signed with the tarsnap-public-keys. That doesn't prevent tarsnap-gui from being modified after the fact, but it's a guarantee that the Tarsnap.app installed by Cask was vetted by the Tarsnap team.

what's the bin/tarsnap-gui script for?

The reason for the shell script was to support the binary stanza, allowing tarsnap-gui to be placed on the user's PATH. (I tried linking Tarsnap.app/Contents/MacOS/Tarsnap directly, but running it from outside the .app directory results in Qt framework loading errors.)

The other benefit of this model is that it simplifies log collection, since the script can automatically pipe stdout and stderr someplace on disk.

But the downside is as you say: extra complexity, which may be worth avoiding. I don't have any strong feelings either way.

why did you add a build-osx.sh? What does it fix that the non-cask TarsnapGui's install section does?

Solely convenience. I think a Cask formula needs to ship either a .zip or a .dmg, so there would have to be an extra step added to the build process anyway. And since I was testing many iterations of the .app, I eventually just automated it.

It doesn't need to be merged into master (though FWIW it does work on Ubuntu as well).

[shawwn]

(Oh, and I didn't mean to imply that the cask was production-ready. Apologies if that was unclear. It was only intended as an experiment to explore some possible solutions to existing problems, and a starting point for what a production-ready cask formula might look like.)

[gperciva]

Yikes:

The reason for the shell script was to support the binary stanza, allowing tarsnap-gui to be placed on the user's PATH. (I tried linking Tarsnap.app/Contents/MacOS/Tarsnap directly, but running it from outside the .app directory results in Qt framework loading errors.)

Ok, that's a strong reason in favor of it! (BTW, that's exactly the kind of text we like to see in commit messages.)

I'd like to investigate the loading error a bit more, and try to dig up a link to the Qt or OSX docs to show why those errors are expected (i.e. the desired behaviour isn't supported) or a link to a bug report about it. But other than that bit of housekeeping, I'm totally on board with the shell script.

[gperciva]

More info about this in Tarsnap/tarsnap#316.

[amarendra]

Just tried it multiple times on Sonoma and tarnsap-gui doesn't show up in /Applications. It's from 2018 but I see the issue is still open. Is there any other way to install the GUI on mac Sonoma so that I can use it on my new laptop.