[Install] Useability: Add ability to Install Plain Brew packages, not just Casks.

[AnneTheAgile]

hi! I see that a tiny program, devtodo [1], has a brew but not a cask [2]. That makes sense - it's not an app.

# No Cask , per Search and List, for DevTodo
$ brew cask search devtodo
No Cask found for "devtodo".
$ brew cask list devtodo
Error: No available Cask for devtodo
$ echo $?
1

# It does have a Brew
$ brew  search devtodo
devtodo
# Can edit the formula or view Homepage URL
$ brew edit devtodo
$ brew home devtodo

I'm integrating Mac OSX provisioning with Ansible and Homebrew-cask through a playbook. At first I was using hnakamur's playbooks [3], but now I see actually both casks and brews are now on the 'extras' repo in the main ansible project [4].

At any rate, my question or idea for a feature is about useability.

As a user, why do I need to care about whether the package available as a binary or an app/dmg? I'd like brew-cask, upon failure, to check brew itself for a formula and then use that if discovered.

One of the worst things about the zillions of package managers is having to know whether the package has a recipe and how to create one. It seems that at least for brew/cask , since they go together it would be nice to hide this detail where possible. Otherwise I have to know which is available, or neither, before I try to install.

A contrary view is that good Unix philosophy divides up the projects, so they should remain separate. That idea seems to indicate a solution would need to be an entirely new project. That seems a bit much though, especially given the popularity of brew/cask.

Thoughts? Thank you!
AnneTheAgile
ps I love how the contrib page says you love contributions :)
pps I asked on freenode IM but maybe people weren't around much today. [5]

[1] devtodo C++ version-0.1, http://swapoff.org/devtodo.html
[1A] DevToDo needs a new brew for its GoLang version. I did some research and it looks easy to write it, including the Go dependency.
https://github.com/Homebrew/homebrew/blob/master/Library/Contributions/example-formula.rb

depends on :go

[2] Another way to search for Casks is to use Github. Here is a url to hunt for 'mysql' casks. https://github.com/caskroom/homebrew-cask/search?utf8=%E2%9C%93&q=mysql
[3] hnakamur has 20 roles contributed including for brew, brew-cask, and brew-path, https://galaxy.ansible.com/list#/users/20
[4] Ansible/Extras, Search for 'brew' https://github.com/ansible/ansible-modules-extras/search?utf8=%E2%9C%93&q=brew
[5] IM IRC # homebrew http://webchat.freenode.net/

[vitorgalvao]

As a user, why do I need to care about whether the package available as a binary or an app/dmg?

You don’t; homebrew-cask provides both. The difference isn’t between binary and app, but between downloaded as source code that will be compiled, or as an already compiled package. The distinction is important because the result is different. brew install macvim takes (possibly way) longer to install then brew cask install macvim. The former provides flexibility, while the later provides speed. If you don’t care/know about the difference, than you likely shouldn’t be using brew install anyway.

It seems that at least for brew/cask , since they go together

They do now, but there’s a good change they won’t forever. Separating from homebrew is a topic in active discussion. There isn’t that much code in homebrew-cask that depends on homebrew.

I'd like brew-cask, upon failure, to check brew itself for a formula and then use that if discovered.

Ethically, I’d argue that could be seen as devaluing their work a bit (“why care about brew at all? Just brew cask everything.”). Technically, I see it as being misleading. As stated before, brew and brew cask are different commands that do different things; why should we assume the user automatically wants the former if the latter doesn’t work? That’d be akin to running trash, and it just executing rm it it weren’t available. They’re not the same thing, and should not override each other.

my question or idea for a feature is about useability.

But there’s one thing that is insanely more important than usability, particularly in a Unix-style CLI tool: predictability. If I tell a command to do something, it better not go on a tangent and do something else differently, unless I give it explicit permission beforehand. If homebrew and homebrew-cask produced the same result in the end, then sure, it’d be acceptable. However, they don’t, so it isn’t.

All that said, informing the user about a package being available somewhere else isn’t harmful (I’m not sure it’d be all that helpful, though).

IM IRC # homebrew

We’re at #homebrew-cask.

[AnneTheAgile]

@vitorgalvao , thank you for such a detailed explanation!

It makes alot more sense now, I had not realized that originally HomeBrew focused only on source code. They say they prefer to provide binaries, per the FAQ, as I read it.
https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/FAQ.md#faq
homebrew/FAQ.md

Why do you compile everything? Projects distribute source tarballs, generally, but if they provide a good binary, we’ll use it. Though we don’t always.... These pre-compiled versions are referred to as bottles... If available, bottled binaries will be used by default... We aim to bottle everything.

I confirmed the default will often give a bottle, per my memory and this SO post example.
http://stackoverflow.com/questions/25075888/brew-install-postgresql-upgrade-error-could-not-link-dead-links-to-old-non

I found how to force re-compiling from Source;
http://stackoverflow.com/questions/23484623/how-can-i-force-homebrew-to-recompile
How can I force homebrew to recompile? - Stack Overflow

$ brew install --build-from-source THEPKG

Do you know the options to see the choices of Source-Brew or Binary-Bottle?
thank you!

//edit found source info

[vitorgalvao]

They explain it on the FAQ. Bottles are used only if available and no options were passed on the command line. To force an install from source without passing any specific install flags, use --build-from-source.

[AnneTheAgile]

ty @vitorgalvao ! I do wish it were simpler, but we all know that installing is not always simple :). So it makes sense to have separate options.