homebrew-cask: Remove casks which duplicate Homebrew formulae

Hi all! I am going to integrate Homebrew and Cask closer (as my GSOC project this summer) and I tried to list what should be removed in which case. Could you please review the list and correct me if I am wrong? I thought that all languages could go as formulas for consistency.

name	type	reason
avidemux.rb	cask	GUI, binary (but has homebrew guide on website)
basex.rb	both	Different
boot2docker.rb	formula	deprecated (migrate to docker-toolbox), binaries
cmake.rb	both	installing different things
consul-template.rb	formula	CLI, open-source
consul.rb	formula	CLI, open-source
cryptol.rb	formula	Lang, open-source
cups-pdf.rb	formula	Driver, not GUI
cvc4.rb	formula	CLI, open-source
davmail.rb	both	Installing different things, personal or server
dmd.rb	formula	Lang, open-source
docker-compose.rb	formula	CLI, open-source
docker.rb	formula	CLI, open-source
doxygen.rb	both	Installing different things (Cask with GUI)
emacs.rb	both	Both
fish.rb	formula	CLI, open-source
fontforge.rb	both	Installing different things (both instructions on github)
fpc.rb	formula	Lang, open-source
gedit.rb	cask	GUI, open-source
ghc.rb	formula	Lang, open-source
gimp.rb	cask	GUI, (consistency)
git-annex.rb	formula	CLI, open-source
git.rb	both	Different
go.rb	formula	Lang
graphviz.rb	both	see #3103
heroku-toolbelt.rb	formula	Cask deleted already
horndis.rb	cask	Driver, (drivers in cask ?)
hub.rb	formula	CLI, open-source
idris.rb	formula	Lang, open-source
jenkins.rb	formula	CLI, open-source
kdiff3.rb	cask	GUI, .app,  open-source
macvim.rb	cask	GUI, open-source
metabase.rb	both	Different
mitmproxy.rb	formula	CLI, open-source
mongodb.rb	both	different
ngrok.rb	cask	Formula deleted already
nmap.rb	both	different
node.rb	formula	Env, open-source
nomad.rb	formula	CLI, open-source
nzbget.rb	both	different
otto.rb	formula	CLI, open-source
tuntap.rb	cask	Kernel ext, open source
packer.rb	formula	CLI, open-source
pandoc.rb	formula	CLI, open-source
pgloader.rb	formula	CLI, open-source
phantomjs.rb	formula	CLI, open-source
platypus.rb	both	different
purescript.rb	formula	Lang, open-source
python.rb	formula	Lang, open-source
python3.rb	formula	Lang, open-source
quassel.rb	cask	GUI, open-source
racket.rb	formula	Lang, open-source
r.rb(science)	formula	Lang, open-source
rust.rb	formula	Lang, open-source
sickbeard.rb	formula	CLI, open-source
sqlitebrowser.rb	cask	GUI, open source
srclib.rb	formula	CLI, open-source
sslmate.rb	formula	CLI, brew tutorial on site
stack/haskell-stack	both	Different, rename
syncthing.rb	formula	(consider https://github.com/caskroom/homebrew-cask/issues/15603#issuecomment-172669690)
terraform.rb	formula	CLI, open-source
tuntap.rb	cask	Kernel ext, open source
unison.rb	both	Different
vault.rb	formula	CLI, open-source
volatility.rb	formula	CLI, open-source
wireshark.rb	formula	see #3341

I have been finishing this issue today. Some of the remaining ones were different, others had already been fixed. Moved some to “Resolved” but stopped as there isn’t much point now.

Closing the issue as finally done. A year to get it all done isn’t all that bad, considering the scope of such task. Thank you all for the work on this.

There are some that suffered no modifications and exist as both cask and formula with the same name. Those are simply too valuable and divisive to formula and cask users to deprecate one in favour of the other. It might happen, but not now. I don’t think they’ll be controversial:

• emacs cask, formula
• macvim cask, formula
• wireshark cask, formula

Edited top list to keep what’s still missing at the top for easier checking. Also removed on hold label, since this is very much underway.

@vitorgalvao thanks - I figured that would likely be your take. I’ll try and get it done sometime.

I don’t know about brightness, but I think corectl and redis should be formula only.

grip.rb: Formula and cask are different, completely-unrelated projects.

Also, the formula links in the top post are broken — need to remove the Library/ component from paths.

When I understand what keeps brew update from deleting and moving casks properly later this week I hope, I’ll start some PRs here in cask as I’m already doing in brew so that discussion can be continued there.

The brew GHC formula is relocatable to any prefix, so the app bundle is basically a red herring. What it’s doing is installing ghc, stack, and cabal-install, all three of which brew already provides.

Understood. @AnastasiaSulyagina, would you mind updating your list to make ghc formula-only?

https://github.com/Homebrew/legacy-homebrew/pull/46796#issuecomment-162950415:

I guess the only big advantage of this change is bottling the Cocoa version, since I’m willing to bet that it’s what most people want.

Is that true? I find it hard to believe that most people want an app bundle for Emacs. For the record, I personally build emacs with --with-cocoa as well as a bunch of other options, not that I really use the Cocoa interface, but for the sake of completeness and testing (once in a while, when testing package bugs and such).

By the way, from Mike’s comments in https://github.com/Homebrew/legacy-homebrew/pull/46796 he doesn’t seem to favor app bundles in any official taps other than HBC.

@DomT4 https://github.com/caskroom/homebrew-cask/issues/15603#issuecomment-223135849

Almost as many people are building emacs --with-cocoa as are pouring vanilla emacs bottles.

Is that based on hard analytics data?

Before we go further with duplicate removals, implementing better search should be a priority.

Some thoughts:

Many of these formula have bottles over in homebrew, which means that essentially, they are just putting a prebuilt binary (if possible), which would be the same behavior as what the Cask does. The difference, as far as I understand (please correct me if I’m wrong), is that homebrew can also build from source, whereas homebrew-cask has no support for such an option.

I took a quick look at homebrew/binary and it seems as the Cask DSL (as it’s developed) is more suitable for easy contributions and (the version stanza plus string interpolation is great, and the lower barrier to entry is something I don’t want to lose in an eventual merge).

homebrew/binary does have a few duplicates (i.e. ngrok), but it doesn’t seem user friendly to just remove either. As it stands, someone could run brew install ngrok, brew install binary/ngrok, and brew cask install ngrok, and get two (or sometimes 3) different results.

Following from the above, homebrew/binary seems like it should only handle command-line only tools, and homebrew-cask GUI applications (and their associated binaries, if needed). I believe this may have been the original goal but things may have gotten muddled over time.

(meta): We should add all these issues to a “cleanup” or “pre-merge” milestone so we can see progress.

Great work everyone 🎉

@joshka Considering it’s open-source, CLI-only, there is already talks to make it a formula, and other formulas will be able to use it, this all points to a formula instead of a cask, if it can be done.

There’s a request that’s been open for some time to add a dotnet formula. It currently exists in homebrew-cask. Microsoft distributes it both as source code and a .pkg installer that installs to /usr/local/. Is there a current guideline for whether this would be right for homebrew vs homebrew-cask, or is this question still being resolved?

See https://github.com/dotnet/cli/issues/533

For boot2docker, yes I’d kill both since the non-deprecated replacements are already in Homebrew (https://github.com/Homebrew/homebrew-core/blob/master/Formula/docker-machine.rb) and Cask (https://github.com/caskroom/homebrew-cask/blob/master/Casks/docker-toolbox.rb).

I’ll look at it. And could anybody update list on the top please? There are not many left and all of them are ones that I’m not sure about.

ILZ can be a little blunt humoured, but he’s full of love really.

There’s additional discussion in https://github.com/Homebrew/homebrew-core/issues/2260, but I agree largely this is going to need to be debated case-by-case & it’s sensible not to hold lengthy debates in what is more or less a tracking thread.

Let’s move cask-specific discussions to separate issues. There are a lot of participants on this thread, and I doubt they’re all particularly interested in the fate of GHC 😉

They are not different things, sorry. It’s redundant with everything we do in brew with Haskell stuff.

@vitorgalvao I would happily see the GHC cask removed, for instance.

@chdiza Nope, we’re going to go by what analytics say people are actually using.

@xu-cheng Are you personally committed to fixing issues in MacVim that come up for users?

But there is still a strong need to build it from source for the very reason to choose what Python/Perl/Ruby it links to so some plugins can work. The similar case can be applied to emacs --with-cocoa. Users may need a custom build for plugins and cocoa for GUI.

I think it’s also worth mentioning that MacVim’s formula causes us a lot of support issues and is something we do not cannot provide a binary package for. It’s worth distinguishing between “things you can do by creating Formulae” and “things Homebrew officially supports”.

When software is heavily reliant on options and Homebrew cannot create binary packages for it: it will have a poor user experience or at least less reliable/predictable than the binary package. Unless we have multiple Homebrew maintainers who strongly feel they want to maintain these in core (and are happy to be held accountable for fixing all issues/reviewing all PRs relating to these) we should defer to the casks officially supported upstream and encourage the community to support all the options they choose in third-party taps.

The goal here should be to have the least amount of effort duplication between projects, while at the same time not stifling user options too much.

To be explicit on this point: our CI and binary packages do not support formula options. Those two things have caused by far the biggest increase in overall project quality in the 7 years I’ve been working on Homebrew. Formulae where most users are not using what our CI is testing and where we cannot generate binary packages have a ceiling of quality that we can reach and, when they are relatively popular, these ceiling of quality detrimentally affects the perceived quality of the entire Homebrew project.

@AnastasiaSulyagina Edited your post simply to fix the link to the syncthing comment.

Will also link to your table from the top post. In addition, I’ll strike the | both | different | ones from the top post.

As for emacs, I have no strong opinion (vim user) and we have homebrew maintainers in this thread discussing that already, so I’m fine with following whatever @MikeMcQuaid and @DomT4 feel is best.

I’ll take a look at the ?s of the table today.

@RandomDSdevel Thank you, added it to the list at the top.

Note, though, that this is a good example of the case mentioned above: the formula allows you to customize the build with compile-time flags, whereas the cask includes whatever the Gimp team decided to enable by default.

Different taps exist precisely because some cases require different rules.

This. There’s also the licensing issues between open-source and closed-source software that make separation of repositories a sensible (and in some cases legal) one.

If the goal is to merge the two projects, does it make any sense to keep Casks and Formulas separated into different repositories?

I think it is much simpler and cleaner to just say “hey, choose the format that makes most sense for your package when contributing and put it in the correct repository based on the ‘old’ contributing guidelines of Homebrew and Cask, without caring about which format you chose”. It wouldn’t matter if the package has a GUI or not or if it is distributed as a binary or as source code.

This would mean that there is one “main” Formula/Cask repository, one named “versions” for Formulas and Casks and so on.

I know that this would make it much harder for the maintainers, since the separation and responsibility the Cask team would keep after the merge would instantly be lost. But this could be changed to say “every change regarding a Cask file is the responsibility of the Cask team and the other way around. The teams are not supposed to change anything else.”.

@mikemcquaid You said: “In the case that it’s binary, proprietary terminal software: Cask is still probably a better fit, I think.” - That would be a source of confusion, especially for the end user.

With that statement, what would be the cue for the user to brew install (binary, proprietary, cli only app) versus brew cask install (binary, proprietary, cli only app), as building from source isn’t necessarily a user’s first thought of the distinction between the two.

The GUI vs, CLI distinction is the “easy” one, but if we also want to account for the “binary, propriety, from vendor” versus “build from source/use bottle” distinction (which I gather is quite important), we end up with the following “classes”:

• 1. GUI-only (or with a helper binary, eg sublime text), proprietary application (will go into Cask, as before)
• 1. GUI-only, but open source (as mentioned by @alebcay)
• 1. binary only, open source software (currently what homebrew is)
• 1. binary only, vendor-supplied binary (currently in Cask)
• 1. binary only, open source, but also has a vendor-supplied binary (which some people prefer to use, as brought up by @bdhess). An example of this is docker.

(Not to mention software like ngrok, where we can be at version 2, but homebrew itself is stuck at v1 because there’s no source available).

---

A tentative proposal:

• 1. keep in caskroom/homebrew-cask (nothing to see here)
• 1. If vendor download available, great, put in caskroom/homebrew-cask. If not, build and host (bintray?) and put in caskroom/unofficial
• 1. keep in homebrew/homebrew (again, nothing to see here)
• 4 & 5. No concrete ideas yet, but this decision basically depends on if the GUI vs binary or open source vs closed source split is “more important”

(I’m leaning towards keep caskroom/homebrew-cask for GUIs, and allow vendor-supplied binaries in homebrew/homebrew, as it seems more user friendly).

Another idea would be to keep the build-from-source vs vendor binary distinction, but pass brew install commands of proprietary, binary only CLI tools through to brew cask install, possibly via the use of a dummy formula over in homebrew/homebrew