Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove casks which duplicate Homebrew formulae #15603

Closed
jawshooah opened this issue Dec 4, 2015 · 154 comments
Closed

Remove casks which duplicate Homebrew formulae #15603

jawshooah opened this issue Dec 4, 2015 · 154 comments

Comments

@jawshooah
Copy link
Contributor

jawshooah commented Dec 4, 2015 •
edited by vitorgalvao
Loading

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

Resolved conflicts
@jawshooah
Copy link
Contributor Author

jawshooah commented Dec 4, 2015 •
edited
Loading

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
Copy link
Contributor Author

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
Copy link
Member

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

@jawshooah
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor

adidalal commented Dec 5, 2015

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
Copy link
Member

@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
Copy link
Member

miccal commented Dec 5, 2015

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

@MikeMcQuaid
Copy link
Member

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?

@jawshooah jawshooah mentioned this issue Dec 7, 2015
Closed
@vitorgalvao
Copy link
Member

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 divisions1 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.

1 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
Copy link
Member

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
Copy link
Member

alebcay commented Dec 7, 2015

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
Copy link
Member

@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.

@adidalal
Copy link
Contributor

adidalal commented Dec 7, 2015

@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

@MikeMcQuaid
Copy link
Member

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

Homebrew already returns casks in search results and if you brew install something that doesn't exist. Homebrew Cask could do the inverse and then we'd be all good.

@MikeMcQuaid MikeMcQuaid mentioned this issue Dec 8, 2015
Closed
@adidalal adidalal mentioned this issue Dec 10, 2015
Closed
@MikeMcQuaid MikeMcQuaid mentioned this issue Dec 10, 2015
Closed
kdeldycke added a commit to kdeldycke/dotfiles that referenced this issue Dec 15, 2015
@kdeldycke
Use formula over casks when possible.
1a606e9 
See: Homebrew/homebrew-cask#15603
@jawshooah jawshooah mentioned this issue Dec 21, 2015
Closed
@lukasbestle
Copy link
Contributor

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.".

@vitorgalvao
Copy link
Member

@lukasbestle I see a lot of downsides (harder to maintain, user confusion) and no upside. Casks and Formulas are very different, not only in structure but in goals. Having them bundled together seems like a recipe for disaster. You’ll still have to brew cask to install them, so having them separate makes absolute sense.

There’s no benefit to making things harder (and in your own words much harder) for maintainers. If we have a harder time managing, project quality will also suffer, and hence users. In addition, it means that when we checked our notifications page on github, we’d be flooded with notifications we’d have no interest or business messing with, and having different rules (which we do, since we’re serving different needs) would be that much harder.

@lukasbestle
Copy link
Contributor

That's very true!

But I think you will need to define and document the difference between Homebrew and Cask very clearly then. Otherwise the current confusion and mixture of similar Formulas and Casks into the different repositories will continue and be way worse then because of the close relation of the two projects.

@vitorgalvao
Copy link
Member

We already see some modicum of confusion (like users making bug reports to the wrong project), but it is negligible and only going down. I don’t think having both projects under the same organisation will be that big of a deal. As long as you still need to brew cask to install some things and not need it to install others you should be able to understand you’re doing different things (else, why would you need different commands?).

From the user’s point of view, we’re akin to a different tap geared towards GUI applications. Taps within homebrew’s organization (and the caskroom organisation) already have different rules. Different taps exist precisely because some cases require different rules.

In addition, the goal of this issue is precisely to reduce duplication, so confusion between which cask/formula to install should go down (since you only have one), not up.

@MikeMcQuaid
Copy link
Member

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.

@lukasbestle
Copy link
Contributor

Specific and clearly defined taps are no problem at all, as long as they are, well, clearly defined. So I'm confident you guys will find a great solution. 👍

Also I forgot that brew cask will continue to exist and be required to handle Casks. So that's fine. ;)

@vitorgalvao vitorgalvao mentioned this issue Jan 5, 2016
Closed
2 tasks
@zmwangx
Copy link
Contributor

zmwangx commented Jan 8, 2016

A duplicate I recently noticed: formula haskell-stack.rb, cask stack.rb. Both installs the Haskell Tool Stack. It's basically a single binary, where the binary distribution installed by Cask also comes with some docs in Markdown. As said it's a single binary intended for command line, so it belongs to brew better.

@vitorgalvao vitorgalvao mentioned this issue Feb 10, 2017
Closed
9 tasks
@miccal miccal mentioned this issue Feb 12, 2017
Closed
9 tasks
@jpadilla jpadilla mentioned this issue Feb 18, 2017
Merged
9 tasks
@vitorgalvao vitorgalvao mentioned this issue Feb 20, 2017
Closed
8 tasks
@claui claui mentioned this issue Feb 27, 2017
Closed
9 tasks
@vitorgalvao vitorgalvao mentioned this issue Mar 16, 2017
Closed
9 tasks
This was referenced Apr 1, 2017
Closed
Merged
@BenjaminHCCarr BenjaminHCCarr mentioned this issue Apr 4, 2017
Closed
@wickles
Copy link
Contributor

wickles commented Jun 6, 2017

What about brew mono vs cask mono-mdk? It seems like they both offer the MDK, but the Framework/PKG version from Cask provided by upstream ends up installing to 3x more space on disk, and overwrites the Homebrew bins. However it seems like some dependent apps that I've tested require the Framework version. What exactly is the difference, why is the Framework so much larger?

Side note, seems like the remaining duplicates don't mention the conflicts/caveats? Would that be reasonable to add to the Casks maybe?

@MikeMcQuaid
Copy link
Member

@wickles It sounds like the mono-mdk is worth removing when we've ensured they install the same files/frameworks.

@vitorgalvao vitorgalvao mentioned this issue Jun 18, 2017
Closed
10 tasks
@commitay commitay mentioned this issue Jun 30, 2017
Closed
9 tasks
@commitay commitay mentioned this issue Sep 28, 2017
Closed
9 tasks
@commitay commitay mentioned this issue Oct 19, 2017
Closed
@vitorgalvao vitorgalvao mentioned this issue Oct 26, 2017
Merged
9 tasks
This was referenced Dec 1, 2017
Closed
Closed
@wickles wickles mentioned this issue Dec 20, 2017
Closed
1 task
This was referenced Jan 14, 2018
Closed
Closed
Closed
@vitorgalvao vitorgalvao mentioned this issue Feb 11, 2018
Closed
9 tasks
@commitay commitay mentioned this issue Feb 13, 2018
Closed
9 tasks
@commitay commitay mentioned this issue Mar 2, 2018
Closed
9 tasks
@vitorgalvao vitorgalvao mentioned this issue Apr 17, 2018
Closed
9 tasks
@commitay commitay mentioned this issue Apr 17, 2018
Closed
1 task
@vitorgalvao vitorgalvao mentioned this issue Apr 21, 2018
Closed
9 tasks
@vitorgalvao vitorgalvao mentioned this issue May 1, 2018
Closed
9 tasks
@lock lock bot locked as resolved and limited conversation to collaborators May 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests