Make caskroom configurable

[ralphschindler]

I can't find the conversation/issue of where the caskroom was moved from /usr/local to /opt.

In any case, how can one something other than /opt? Or perhaps configure it go to back to /usr/local/Caskroom?

[passcod]

The reason the caskroom was moved to opt is that it gives us free integration with Spotlight search. #99 is the discussion you're looking for.

Regarding configuration... I'm not sure. It could be done, but what is your use case? Is there a non-negotiable reason you cannot use /opt?

[ralphschindler]

Hi @passcod,

I suppose the argument is purely philosophical. I stay away from software that uses /opt, which is entirely the same reason I never used macports.

Ideally, and I guess I was expecting, an automated solution to download+drag, which basically means that the .app directory physically resides in the configured place (in my case, would be /Applications).

Personally, I don't use spotlight, I use Quicksliver, which has no problems finding apps in /usr/local.

If this is not something you wish to consider, please feel free to close this.

[passcod]

I stay away from software that uses /opt

The question is more why (what's your non-negotiable reason?) you do that. I see little difference between /opt and /usr/local, except a dozen characters, especially on Mac (would this be Linux or BSD, I'd understand, but would this be Linux or BSD the problem wouldn't arise because these platforms already have good package management).

Aside from philo, I am not against an option to change the caskroom, but I think @phinze or @vitorgalvao would be. So. What are your options?

• Don't use cask.
• Hack cask.

For the second option, have a look at lib/cask.rb, line 21, and change this to whatever you want. The file you need to change is in /usr/local/Cellar/brew-cask/VERSION/rubylib iirc, and you will need to change it whenever we cut a new release and you update (and for the longer term, you might want to make up a custom formula or script for patching this up). The file in /usr/local/Library/Taps/phinze-cask/lib is not used, do not change it (as that will break brew update for casks).

[ralphschindler]

The question is more why (what's your non-negotiable reason?) you do that.

Well, in short, there is already a place for everything in OSX, in fact, multiple. We already have /Application/ ~/Applications, /usr/local. OSX makes no assumption that /Application and ~/Application are for system only applications, and thus most applications are installed there by users. (For single users systems, almost 100% in just /Applications). /opt doesn't exist on OSX. Creating it adds to the breadth root filesystem, and also creates a Finder available directory (by default most POSIX directories are hidden, do ls -lO in the root to see).

Remember I said this was purely philosophical right? ;) For me, the line in the sand between vanity and pragmatism ends just before /opt.

Also, most apps that are installed via cask come with their own software update mechanism, so having a version controlled binary application system makes less sense to me in that regard.

BTW, have you guys consdiered creating file aliases instead of links to solve the "show up in Finder" problem? Like this:

$ osascript -e 'tell application "Finder" to make alias file to POSIX file "/Applications/Xcode.app/Contents/Applications/OpenGL ES Performance Detective.app" at POSIX file "/Users/mylogin/Applications"'

Aside from philo, I am not against an option to change the caskroom, but I think @phinze or @vitorgalvao would be.

So, long story short - why be against a configurable option? If you don't like it, don't use it, right?

[passcod]

The aliasing issue was thoroughly discussed already and /opt was chosen as the simpler of two possible solutions, which didn't include the one you propose, because it doesn't quite work (see #188).

We'll have to wait on the others to weigh in, but the 'don't want it don't use it' argument also can results in cruft and extra maintenance.

The explanation regarding /opt appearing in finder is interesting... but, does that mean we could have a /Caskroom and it would work? If not, /opt is indeed special.

[altryne]

I have to chime in here and agree with @ralphschindler
I'm using Alfred to launch my apps, and it seems even though spotlight finds the apps, Alfred doesn't.
This may be an Alfred issue.
But I'm also using CleanMyMac for uninstalling applications.
And it can't find apps by cask as well.

So it seems if one wants use cask for automation of downloading, but not nessesarally managing, it's going to be difficult as the tools out there ignore links in /Application folders.

[vitorgalvao]

I completely forgot about this discussion, but I definitely intended to respond before. I’m on a tiny keyboard and screen, here, but I’ll try to be brief and clear.

In truth, I don't really care where the directory is, as long as it's out of the way, and it contains everything, although that may be due to me not using homebrew-cask the way it was intended (I use it to get the executables, that are then moved to /Applications). That’s actually pretty easy to do, I just call a simple script (that I didn’t yet have the chance to test properly, but that seems to work well enough).

However, as @passcod said, there’s a reason the directory was changed to /opt — it was deemed a better solution, and I do think implementing code to customize the location of the apps, particularly this early in the project, would be diverting resources away from more pressing features. It’s something that could possibly be revisited later on (the /Caskroom idea also did not bother me at all, I actually thought the same thing, when I was reading this the first time).

Regarding the integration with Alfred, there’s a command for that (brew cask alfred).

[altryne]

Thanx @vitorgalvao
I've decided to build my own integration with @alfred
That does search on cask repository and installs it to ~/Applications
https://github.com/altryne/install_apps_alfred/

[halo]

I have a feeling that this is a recurring issue and my reasons are not related to Spotlight or Alfred, but by the simple fact that I don't want to be dependent on sudo (which I perceive to be a quite common use case). Plus, I don't want any tool to spread out all over my hard disk without me having knowledge of it :)

I might be naive, but wouldn't a simple thing such as this, used in combination with HOMEBREW_CASK_OPTS in .bash_profile solve this?

I quickly tried a HOMEBREW_CASK_OPTS="--caskroom=/tmp" brew cask install cyberduck and it works just fine.

Homebrew can be entirely configured so that all applications are sandboxed and reside inside the homebrew directory. Why can't we? :)

EDIT: Or why not use $(brew --prefix) alltogether as a prefix for determining whether casks should be installed to /opt/... or /path/to/homebrew/opt/.... That would be much more consistent. In most cases it's going to be /opt anywhay. And those who want their homebrew somewhere else, well, they'll get their caskroom somewhere else, too, without cracking their brains.

[vitorgalvao]

As I’ve said before, I don’t really care for the location of the Caskroom, as long as it works well. However, I can certainly see the reasoning/need for having it configurable, and I’m all for it. I’ve said at the time that I thought this is “something that could possibly be revisited later on” — I believe we’ve reached that stage.

Having said that, I’d like to address some of your other points.

Regarding the comment that you mentioned (concerning linking), my answer is that this is not homebrew, we’re not installing mainly command line apps (where you add a line to your shell’s startup files and deal with them all) with some having a GUI — almost all of the apps we deal with have a GUI, and most users expect to see them in a standard directory. However, this has been configurable for some time, so if you’d like other directory to be the default, that’s a line of code away. On a related note, brew linkapps does link outside it’s directory by default (to /Applications), so they also understand this different case needs a different solution.

Plus, I don't want any tool to spread out all over my hard disk without me having knowledge of it

Neither do we, that’s why we try to reduce that to a minimum — it only happens on installations (like .pkg files), where there’s not much we can do most (all?) of the time, and with linking (reason above).

Homebrew can be entirely configured so that all applications are sandboxed and reside inside the homebrew directory. Why can't we?

Well, I wouldn’t call them exactly sandboxed. They still have access to your system like any other app, an even drop their configurations in your home dir (or wherever they’re setup to); they’re just installed to a different directory, which is exactly what we do (with the exception of .pkg installs, as stated before). If you want to configure your apps to be entirely sandboxed, though, then homebrew is definitely not accomplishing that (nor is it meant to).

[halo]

Well, then we're on the same page :) Thanks for the in-depth explanation.

So what do you think about the simple solution I thought about? Wouldn't that cover 99% of the use cases? Plus, totally unobstrusive.

PS:

...and even drop their configurations in your home dir (or wherever they’re setup to)...

Every homebrew application (at least each one I encountered) is by default configured to not leave any configuration data outside of the homebrew directory. That's what I mean by "sandboxed".

[vitorgalvao]

Submit a PR with it. This way we’ll have a place to talk about implementation (as opposed to just “should this be done at all?”), specially since this issue had stayed untouched for 6 months. I have no problem at all with this feature, but others might (I haven’t been much to IRC, lately, so maybe this was even discussed there, lately, and there were some points that I’ve missed).

[halo]

Sounds good, thank you for your thoughts on this. Pull request: #2066

[phinze]

Landed! ✈️