Remove casks which duplicate Homebrew formulae

[jawshooah]

As discussed in #14384, we will soon begin an effort to integrate Homebrew-Cask directly into Homebrew, which requires that we eliminate any casks which duplicate existing Homebrew formulae.

---

Remaining conflicts

• boot2docker.rb cask, formula
• brightness.rb cask, formula (different)
• cocoapods.rb cask, formula
• corectl.rb cask, formula
• crunch.rb cask, formula (different)
• cura.rb cask (cura), formula (curaengine)
• emacs.rb cask, formula
• ghc.rb cask, formula
• jasper.rb cask, formula (different)
• macvim.rb cask, formula
• mat.rb cask, formula (different)
• metabase.rb cask, formula
• mu.rb cask, formula (different)
• rabbitmq.rb cask, formula
• snappy.rb cask, formula (different)
• wireshark.rb cask, formula

Resolved conflicts

• avidemux.rb cask, formula (moved to Homebrew Cask)
• azure-cli.rb cask, formula (moved to Homebrew)
• basex.rb cask, formula (different)
• bee.rb cask, formula (different)
• chicken.rb cask, formula (different)
• cmake.rb cask, formula (different)
• consul-template.rb cask, formula (moved to Homebrew)
• consul.rb cask, formula (moved to Homebrew)
• cryptol.rb cask, formula (moved to Homebrew)
• cups-pdf.rb cask, formula (moved to Homebrew)
• cvc4.rb cask, formula (kept in Homebrew-Cask)
• dash.rb cask, formula (different)
• davmail.rb cask, formula (different)
• dmd.rb cask, formula (moved to Homebrew)
• docker-compose.rb cask, formula (moved to Homebrew)
• docker-machine.rb cask, formula
• docker.rb cask, formula (different)
• doxygen.rb cask, formula (different)
• dterm.rb cask, formula (different)
• emojify.rb cask, formula (different)
• exiftool.rb cask, formula (moved to Homebrew)
• fabric.rb cask, formula (different)
• fish.rb cask, formula (Remove fish, renamefishapp to fish. #23191)
• flow.rb cask, formula (different)
• fontforge.rb cask, formula (different)
• fpc.rb cask, formula (moved to Homebrew)
• fugu.rb cask, formula (different)
• geany.rb cask, formula
• gedit.rb cask, formula (moved to Homebrew)
• gimp.rb cask, formula (moved to Homebrew-Cask)
• git-annex.rb cask, formula
• git.rb cask, formula (different)
• gitup.rb cask, formula (different)
• go.rb cask, formula (moved to Homebrew)
• graphviz.rb cask, formula (moved to Homebrew)
• grip.rb cask, formula (different)
• heroku-toolbelt.rb cask, formula (moved to Homebrew)
• hive.rb cask, formula (different)
• horndis.rb cask, formula (moved to Homebrew Cask)
• hub.rb cask, formula (moved to Homebrew)
• hyper.rb cask, formula (moved to Homebrew)
• idris.rb cask, formula (moved to Homebrew)
• jenkins.rb cask, formula (moved to Homebrew)
• jing.rb cask, formula (different)
• kdiff3.rb cask, formula (moved to Homebrew-Cask)
• keybase.rb cask, formula (install different things, GUI vs CLI)
• knock.rb cask, formula (different)
• lightning.rb cask, formula (different)
• mitmproxy.rb cask, formula (moved to Homebrew)
• mongodb.rb cask, formula (different)
• mpv.rb cask, formula
• namebench.rb cask, formula (cask install GUI, formula install CLI)
• ngrok.rb cask, formula
• nmap.rb cask, formula (different)
• node.rb cask, formula (moved to Homebrew)
• nomad.rb cask, formula (moved to Homebrew)
• nzbget.rb cask, formula (different)
• octave.rb cask, formula - in homebrew-science
• orbit.rb cask, formula (different)
• osxfuse.rb cask, formula - Cask should stay
• otto.rb cask, formula (moved to Homebrew)
• packer.rb cask, formula (moved to Homebrew)
• pandoc.rb cask, formula (moved to Homebrew)
• pgloader.rb cask, formula (moved to Homebrew)
• phantomjs.rb cask, formula (moved to Homebrew)
• platypus.rb cask, formula (different)
• purescript.rb cask, formula (moved to Homebrew)
• python.rb cask, formula (moved to Homebrew)
• python3.rb cask, formula (moved to Homebrew)
• quassel.rb cask, formula (moved to Homebrew-Cask)
• r.rb cask, formula - in homebrew-science (moved to Homebrew)
• racket.rb cask, formula (Formula renamed)
• raptor.rb cask, formula (different)
• redis.rb cask, formula (moved to Homebrew)
• rethinkdb.rb cask, formula
• rust.rb cask, formula (moved to Homebrew)
• serf.rb cask, formula (moved to Homebrew)
• sickbeard.rb cask, formula (moved to Homebrew)
• smlnj.rb cask, formula
• spark.rb cask, formula (different)
• sqlitebrowser.rb cask, formula (moved to Cask)
• squirrel.rb cask, formula (different)
• srclib.rb cask, formula (moved to Homebrew)
• sslmate.rb cask, formula (moved to Homebrew)
• stack/haskell-stack cask, formula (different)
• subnetcalc.rb cask, formula (different)
• swi-prolog.rb cask, formula (moved to Homebrew)
• syncthing.rb cask, formula (consider Remove casks which duplicate Homebrew formulae #15603 (comment)) (moved to Homebrew)
• tag.rb cask, formula (different)
• terraform.rb cask, formula (moved to Homebrew)
• tn5250.rb cask, formula (different)
• transmission.rb cask, formula (same app, but we install different things)
• tuntap.rb cask, formula (Formula was removed)
• unison.rb cask, formula (different)
• vault.rb cask, formula (moved to Homebrew)
• volatility.rb cask, formula (moved to Homebrew)
• wakeonlan.rb cask, formula (different)

[jawshooah]

FYI, here's the script I used to generate the list:

brews = `ls $(brew --repository)/Library/Formula`.split("\n")
casks = `ls $(brew --repository)/Library/Taps/caskroom/homebrew-cask/Casks`.split("\n")
common = brews & casks
common.each do |x|
  cask_url = "https://github.com/caskroom/homebrew-cask/blob/master/Casks/#{x}"
  brew_url = "https://github.com/Homebrew/homebrew-core/blob/master/Library/Formula/#{x}"
  puts "- [ ] #{x} [cask](#{cask_url}), [formula](#{brew_url})"
end

[jawshooah]

Note that some of these casks may actually be different programs that happen to have the same name as a Homebrew formula. We should be careful to remove only those casks which actually duplicate programs available through Homebrew, and come up with a strategy to handle those that don't, likely through some renaming scheme.

[vitorgalvao]

Was just going to say that. Found Dash in there, which fits that case.

[jawshooah]

I'm also not sure how we should handle casks which do install the same program as the corresponding Homebrew formula, but in a fundamentally different way.

For example, the jenkins cask uses a pkg installer, which does a whole lot more than the Homebrew install does.

[vitorgalvao]

I'm also not sure how we should handle casks which do install the same program as the corresponding Homebrew formula, but in a fundamentally different way.

For example, the Jenkins cask uses a pkg installer, which does a whole lot more than the Homebrew install does.

(emphasis mine)

As I see it now, the metric for a duplicate formula/cask should be “do these install the same thing? Can the user do everything with one as they can with the other?” If the answer is “yes”, only one of them should stay (I’d have no quarrel if it were the formula). If the answer is “no”, we (both teams) should discuss why they are different, see if one option is objectively better than the other, and go from there.

Lets call @MikeMcQuaid in here. This really benefits from input from both teams.

---

Interesting cases to consider, on a first look:

transmission: we do install the same app, but different things from it.

ngrok: stuck at version 1 over at homebrew, while we have version 2. The difference is since version 2 isn’t open source, they cannot add it to their main repo, but we can. (ngrok v2 was added to homebrew/binary)

[adidalal]

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.

[vitorgalvao]

@adityadalal924 Quick note regarding homebrew/binary. A long time ago in homebrew-cask’s life, we had to make that decision. Up until a point, we always refused software that could fit into homebrew/binary and suggest users submit there. The moment we reverted that decision came down to a few strong reasons:

• People kept submitting new binaries here. More contributors seemed to know about homebrew-cask than homebrew/binary, for some reason.
• Similarly, people seemed to expect the binaries would be here.
• We had a faster response time. This was, after all, our main repo, and homebrew/binary is secondary to homebrew’s main repo, so that is understandable.
• As you mentioned, our DSL was more suited for those simple contributions.
• We actually could do more than homebrew/binary, since homebrew-cask could support a few extra things, like different package formats not supported by homebrew.

At the time we even discussed speaking with the homebrew maintainers regarding (in a way) dismantling homebrew/binary in favour of homebrew-cask. Perhaps the project merge would be the right time for that.

For the full discussion regarding the decision, see #4228.

[miccal]

Another one for the list is Octave, which is in homebrew/science and Caskroom (although they are different versions).

[MikeMcQuaid]

Thanks for including me @vitorgalvao, I have strong opinions about this and what we can do to make both projects better.

• we were planning on shutting down homebrew/binary in favour of homebrew-cask because Cask is far nicer to use for binary package installation
• in an perfect world we would rename packages so that packages with the same name in both are the same software (as the projects get closer and more integrated)

My biggest point is on focus. The original focus of both these projects (well, my impression at least of Cask, I could be wrong) was that Homebrew was geared towards Unix command-line applications and Cask towards OS X (or cross-platform) GUI applications. I think it would be nice, particularly as the projects come closer together, if we double-down on those focuses. Obviously there's grey lines but I see the Ideal App on both platforms being:

• Homebrew: an open-source command-line application (or library) that builds from source, isn't distributed as a binary and has no GUI component
• Cask: a closed-source GUI .app bundle that's distributed by upstream as an self-updating binary

Thoughts?

[vitorgalvao]

in an perfect world we would rename packages so that packages with the same name in both are the same software (as the projects get closer and more integrated)

That’s a tough one. If (like in the checked examples in the list) there are two separate softwares, one CLI-only and one GUI-only and they share nothing other than a name, I’d say there’s a great chance a user has heard of one but not both. Though we do have rules for it inside HBC (append the vendor to the name of the least popular one), I’m not sure a rule that spans both divisions¹ is the best path.

Since there’ll continue to be something that separates purposes (CLI vs GUI) in users’ minds (having to write cask), that should be good enough to make the distinction.

I’d say it a bit differently, then: in a perfect world, we wouldn’t need to rename, because there would be no overlap. That may also turn out to be an impossibility, though.

---

Regarding focus, you’re right regarding original intent, but there’s a part there that requires clarification. Shutting down homebrew/binary in favour of HBC and making HBC solely GUI focused contradict themselves. Could you develop the thought further?

Also, do you see that as meaning apps such as macvim would come to HBC and be removed from HB? Naturally, binary as an artifact we would keep and use for such cases.

---

¹ When both projects are merged, there’ll still be a thin separation between them and their functions, so I call those different parts “divisions”, here, to be clearer.

[MikeMcQuaid]

Since there’ll continue to be something that separates purposes (CLI vs GUI) in users’ minds (having to write cask), that should be good enough to make the distinction.

👍

Shutting down homebrew/binary in favour of HBC and making HBC solely GUI focused contradict themselves. Could you develop the thought further?

I guess I don't see it as being solely GUI but more that that's the optimum case for each. In the case that it's binary, proprietary terminal software: Cask is still probably a better fit, I think.

Also, do you see that as meaning apps such as macvim would come to HBC and be removed from HB? Naturally, binary as an artifact we would keep and use for such cases.

I'd love to see that happen, personally, but I suspect it may be relatively unpopular. Still, in theory: yes, that's what I'm thinking.

[alebcay]

Are there any ideas on where to stick open-source GUI apps? Most GUI apps do provide binary downloads, but there are occasionally cases where they are source-only. Currently, we handle the situation by building it ourselves and hosting it on caskroom/unofficial.

Personally, I think this process leaves much to be desired. Is there any way options like --build-from-source could be implemented for Homebrew Cask? It may be useful for patches, app options, etc. to be added at the end user's request.

However, there are very few such Casks right now that would benefit from such functionality, and it may not be worth the trouble to implement yet, but it is still an idea I wanted to bring up as a possibility if the need arises.

[MikeMcQuaid]

@alebcay I like the idea of building them yourself using a Homebrew Formula which just generates a single application bundle that you can host. I'm personally 👎 on adding options/patches on top of that as I think the beauty of Cask is the simplicity and adding options makes that harder to accomplish, harder to test and as a result means there's worse quality.