Cellar location for apps

[rgieseke]

Running brew doctor I get a warning

Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:

    caffeine
    github
    notational-velocity

Is Cellar the best place for cask apps?
What about name conflicts with homebrew cli tools?

[phinze]

Putting casks in Cellar gets us a bunch of homebrew idioms like brew list and brew uninstall for free.

The proper permanent location for casks depends on whether or not we want to pursue upstream integration of this project.

Either way - perhaps we can patch upstream homebrew to play nicer with us. This is something to think about. Ideally I'd like to avoid re-implementing all of homebrew's operations for our subset, but I also don't want to make thinks murky and confusing.

[rgieseke]

I see. There is also the space of command line tools like pandoc [1] that come with a .pkg in a .dmg file. It's currently not in homebrew because it could be installed with Haskell's cabal tool I think.
Would be useful to be able to install tools like this with cask as well.

[1] http://johnmacfarlane.net/pandoc/

[phinze]

Definitely. Once we support pkg installers in #14 this sort of stuff is exactly what I'm thinking about for brew-cask.

On Monday, October 8, 2012 at 2:54 PM, Robert Gieseke wrote:

I see. There is also the space of command line tools like pandoc [1] that come with a .pkg ind a .dmg file. It's currently not in homebrew because it could be installed with Haskell's cabal tool I think.
Would be useful to be able to install tools like this with cask as well.
[1] http://johnmacfarlane.net/pandoc/

—
Reply to this email directly or view it on GitHub (#38 (comment)).

[muescha]

Now we have Google Chrome.app in our Cellar. Cool.

for new users its not cool that it is not in the /Application folder ;-)

1. there should be a section where is better described why you use 'Cellar' and why this is cool

2. what this means for uninstalling apps

3. why is linkapps not automatic called after 'brew cask install'

[phinze]

Good points. I'll work on getting these ideas into the README.

On Tuesday, October 9, 2012 at 11:16 AM, muescha wrote:

Now we have Google Chrome.app in our Cellar. Cool.

for new users its not cool that it is not in the /Application folder ;-)

1. there should be a section where is better described why you use 'Cellar' and why this is cool
2. what this means for uninstalling apps
3. why is linkapps not automatic called after 'brew cask install'

—
Reply to this email directly or view it on GitHub (#38 (comment)).

[rgieseke]

Putting casks in Cellar gets us a bunch of homebrew idioms like brew list and brew uninstall for free.

I really like being able to install applications with cask, but why not install applications directly into ~/Applications?
It might be difficult to get Cask playing nicely with upstream Homebrew anyway. Seeing what's in Applications or removing an app there should be easy to do or wrap in a Cask command. One great feature when having apps in the 'Cellar' is of course that old versions are kept (if there are no automated in-app updates). I do this manually now.

How about something like this
cask install firefox --> Firefox in ~/Applications
cask install firefox --system-wide --> Firefox in /Applications
cask install pandoc --> Pandoc binary in /usr/local/bin/
cask update textadept --> Move old app somewhere, put newest in ~/Applications

[phinze]

why not install applications directly into ~/Applications?

The short answer to this would be: for the same reason that Homebrew does not install applications directly into /usr/local.

We don't know up-front precisely what files are going to be in the dmg/zip/tgz/etc, so it's really helpful to have a place to dump all of them safely then iterate through and act on the files we care about. For a .app file this may be symlinking it into ~/Applications or /Applications, for a .pkg file this might be running the installer. For a screensaver it may be symlinking it into the appropriate directory for it to show up in System Preferences.

The reason I implemented this project on top of Homebrew was because I believe that their methodology for managing applications has a lot of merit. I'd prefer to try and work things so that we can keep ourselves Homebrewy both in implementation and idioms. Trying to manage all of ~/Applications would move the project more towards a standalone system, which would mean reimplementing a lot of the Homebrew stuff we lean on now.

Now all that being said, I'm definitely amenable to the idea that the linkapps operation should be run automatically after a cask install. This prevents anybody from having to think about the Cellar for the basic use case, similar to how brew link is automatically run as part of a brew install.

[rgieseke]

Good points, thanks for the explanation!

[muescha]

@phinze can we put this word by word to the readme? i think this fit nice in a FAQ section :-)

[phinze]

@muescha good idea! done and done 👍

The README is getting a little unruly - going to look into splitting it up soon.

Keeping this issue open to track the work towards automatically running linkapps on brew cask install.

[halo]

I might be mistaken, but if I understand things correctly, running linkapps to link casks to ~/Applications is conceptually not the same thing as running brew link for regular homebrew applications.

When I install homebrew in a custom location, say ~/mybrew, then the linking will take place within that location (that is, from ~/mybrew/Cellar/.../mybinary to ~/mybrew/bin/mybinary. Right?

If you plan on linking to ~/Applications automatically, the whole point of using a custom installation path would fall. As a "poweruser" I'm concerned with being able to automate processes using entirely sandboxed installations. IF you plan on autolinking to something outside of homebrew, I strongly suggest that you provide some sort of flag or ENV variable which allows me to opt-out from that linking.

PS: I really like this whole project by the way. Much potential. Even though I am concerned (as some people mentioned above) with potential name conflicts in the Cellar directory. I hope people keep track of this integrational problem :) Even though I totally agree with that the homebrew logic should not be reinvented.

[passcod]

May I just +1 one of @halo's points? Need way more flags/config to customize it all. :)

[passcod]

There was this idea floating around of using /usr/local/Caskroom instead of the Cellar. Putting this here so we don't forget about it.

[phinze]

Hi @passcod; thanks for the issues cleanup you've been working on today!

I'm +1 for getting out of the Cellar. I was thinking of doing this in the
next day or two. Stay tuned!

On Mon, Jan 28, 2013 at 3:22 PM, Félix Saparelli
[email protected]:

There was this idea floating around of using /usr/local/Caskroom instead
of the Cellar. Putting this here so we don't forget about it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-12808836.

[phinze]

Alright so I was feeling bold today and pushed the Caskroom commit! With thanks to @passcod for the name and the original implementation on his fork, let's see if we can pull off this change.

As I mention in the commit message, this change will end up breaking every install in the following ways:

• all installed casks will no longer be reported as installed
• orphans all existing casks in the Cellar
• no automated facility for cleanup or migration of existing casks

The question I have is - should we add any code to make the transition nicer? Or is everyone using this savvy enough to get their installations cleaned up and we can not worry about it as a project?

Thoughts and ideas are welcome.

[phinze]

FWIW here's the one liner I used to migrate my old casks into the Caskroom:

brew doctor | grep '^    ' | for cask in $(cat -); do echo mv /usr/local/{Cellar,Caskroom}/$cask; done

That will print out the commands it wants to run; then if all looks good you can remove the echo to make it so.

[muescha]

Is there a good way to implement this oneliner into cask? Maybe as 'brew cask doctor'? And then printout this or execute this?

[passcod]

We could, but this is a one time thing. Your applications will still work, they just won't be managed by cask anymore. Also, this oneliner is brittle: it assumes whatever brew doctor has a problem with is a Cellar cask, when it could actually be a normal formula which has some kind of trouble, and moving it to the Caskroom could make things very very bad. Just my 2¢

[muescha]

mhhh ... i just care about users who dont read every issue here... because this a 'breaking' change and the fix for it should be communicated in an other way and not hidden somewhere in the (later closed?) issues ...

[passcod]

Ah, yes, I see your point.

[muescha]

and since brew doctor is a wellknown command with brew then a brew cask doctor can include in the future more additional checks and hints like the original command.

[phinze]

The Caskroom is alive and well and we pass brew doctor just fine. Considering this one done. 👍