GUI .app brainstorming

(Tony Lotts) #1

Understandably, the ‘linkapps’ command is deprecated since Spotlight does not work well with symlinks or aliases.

It is suggested by homebrew, to use cask for GUI apps, which will copy the .app to /Applications, rather than link.
However this leaves a feature gap.

Cask’s goals are to install an .app as a pre-compiled binary. However there are a number of GUI app formulae with build options, which would require a compilation from source. These formulae cannot be ported to cask in it’s current state.

I’ve come up with a few suggestions to handle GUI apps that have build options.
A) The .app is copied* to /Applications, just as Cask does.
B) Change cask to support compilation.

*The brew manpage says that Homebrew formulae do not build “proper” .app bundles, but I’m not sure why. In my testing, I was able to copy brew built .apps to /Applications and use without issue.

(Mike McQuaid) #2

The best option is for someone to build the .app once and then submit it to Homebrew Cask to be installed. There’s no good reason to make users build from source.

(Tony Lotts) #3

I agree with that for most GUI apps. However what about those that have assorted build options?

(Tony Lotts) #4

Here are a few examples:

  • emacs
  • emacs-mac (railwaycat/emacsmacport tap)
  • emacs-plus (d12frosted/emacs-plus tap)
  • macvim

(Tony Lotts) #5

Another example is ‘python3’, which has assorted build options, and comes with an assortment of .apps.
Since it comes with .apps, should it be a cask like ‘racket’? What would become of the build options?

(Mike McQuaid) #6

python3 is primarily a command-line application. Ideally standalone apps would be Casks, yes. Upstream software should pick sensible build options (as is done with every binary package manager in the world).

(Tony Lotts) #7

See that’s why I picked the ‘racket’ cask as an example. The 'python3’
package includes a programming language and .apps that support it’s
platform; as a formula. The ‘racket’ package includes a programming
language, and .apps; however it is a cask. The key difference being,
‘racket’ is installed from a DMG; whereas ‘python3’ is not (and has
assorted build options).

"Upstream software should pick sensible build options"
What about mutually exclusive options?

(Mike McQuaid) #8

How does proprietary software handle mutually exclusive options?

(Tony Lotts) #9

There are no build options in that case. There might be a few different builds, marketed as different products, say a light version, and a pro version, for example.

However, I don’t think that open source GUI apps are directly comparable to proprietary software.

(Mike McQuaid) #10

My point is: it’s possible to handle that situation without building from source and it produces a better user experience. Many of the cases for tools that require options do not need them to be mutually exclusive. Sure, it’s harder to do things that way but most good software engineering usually is :wink:

(Conor Randall) #11

But what if there is no upstream distribution of .app files? Part of the requirements is that the apps come from an official source. If upstream does not provide app bundles, but do provide source, then the only way to ensure security is to build from source, which also allows the user to make compile time choices as they see fit.

(Mike McQuaid) #12

We’re a fair bit off topic here but in general I think you understand my points.

(Luis Puerto) #13

I just going to leave here my two cents, since I’ve been dealing with the issue lately.

I really think that the app bundles have to the moved / copied to the applications folder, since id there where should be stored. However, some apps, packages and so, expect to find the app bundle in the cellar folder instead the application folder. For these reason I think the app bundle should be moved to that applications folder, but a symbolic link should be created on its place on the cellar folder.

I did that, and I solved a problem with a package in R that should connect with qgis.

(Joshua McKinney) #14

One of the easy examples to use to show where cask breaks down is mpv (see Formula, Cask). Both are kind of right.

Using git master is recommended, although it may be slightly unstable at times.

The developers treat the versions as random good enough cuts of the code at a particular time, rather than a stable known good version. Often there’s interesting stuff that fixes real problems in master (like fixing the 60fps problems). I’d definitely not want the Formula to disappear for this. The binary build is some guy just compiling on a box somewhere.