Mention homebrew-binary in contributing docs #4228
Conversation
|
Homebrew-binary seems significantly less active than Cask; furthermore, the Cask DSL works rather well with naked binaries. In practice, would it be desirable to divert binary-only casks? |
|
+1 for merge as this doc reflects current practice and saves typing. However, I agree with @ndr-qef that we should consider revisiting this policy in the future. One other point: I don't think homebrew-binary accepts |
|
That would be correct, @rolandwalker, |
|
👍 |
|
At the moment we have an open pull request for sketchtool, which is a cli-only app. It was submitted to homebrew and rejected, but what’s interesting is two owners (@adamv and @jacknagel) suggested homebrew-cask and not homebrew-binary, as the place for submission. With that in mind, and considering this repo is more active and supports |
|
Another point in favor of CLI is that we have built up a good rhythm and should have no problem undertaking the small additional load. |
|
In the past my general strategy for inclusion of any app was basically "Sure - everybody's welcome!" More recently I've encountered a few users who have been confused about what sort of apps they can expect to exist in the Cask repo, which caused me to reconsider my stance. I wondered if we should make a clearer definition of what "belongs" in our repo. But I'm still not really sold on either side. Sounds like the mood here is to make the default policy be for inclusion? If that's the consensus I'd be okay with that - either way definitely +1 for documenting clearly the policy / process. |
|
I say we start accepting binary-only submissions. We already have some, and the line of acceptance is ever more blurry (even amongst maintainers, as @ndr-qef pointed out). A lot of users see homebrew-cask as the right place to submit them, so we can deduce a lot of them will also think of it as the right place to search for them. Since that expectations exists and we’re the best equipped to fulfil it anyway (for reasons previously mentioned, like support for more containers), it makes sense for us to do it. Regarding homebrew-binary, we can make the suggestion to shift the focus on binaries to homebrew-cask, but that might not be entirely desirable (some users might just want a few of them and not want to use this project to do it, if regular homebrew works fine for them). Naturally, their issue tracker is a better place to find this out. |
|
@vitorgalvao I agree. But then do we need to change the docs at all? |
|
@vitorgalvao I'm fine with that. That would ease managing casks. |
|
Accidentally merged this in, I removed it from the repo and kept everything else intact. |
|
@caskroom/maintainers There is some confusion (at least on my part) as to what exactly is the rule we agreed on, in this issue. This is surfacing due to a comment @radeksimko made, that applies (most recently) to cases like packer and terraform (multiple times). From our discussion in this issue, I do believe these should be included. Limiting the rule to “include binaries only if they come in a package format unsupported by homebrew(/binary)” and/or “if the source is not easily available” is confusing, and makes no sense to me. Why should we be filtering submissions based on how they’re compressed (especially since that’s something that can so easily change), or on the source code’s availability (there are many reasons to prefer the binaries, like not having to wait for it to compile)? Another reason we decided for inclusion was that we’re more active than homebrew/binary and many contributors already naturally gravitate towards us for binaries. We have the infrastructure, and our syntax is more familiar to those contributors, so why go against that expectation, and with a confusing (and nonsensical, I believe) “sometimes it’s ok, sometimes it’s not” rule, on top of that? Either way, even if we decide to deny those submissions on those grounds, these cases should be clearly defined. |
|
I think the consensus above is clearly in favor of allowing binaries:
Miscommunication is understandable though. We didn't change the docs (as it was an unwritten rule) so there's no guarantee that all maintainers followed this lengthy discussion. Not everyone is on IRC either. Perhaps we should have sent around an email. @fanquake also requested email for certain other internal/policy decisions. |
|
As previously expressed, I think it desirable to merge binary-only packages. Opinions aside, I very much agree with @vitorgalvao in that clarity is a primary concern. (I might be mistaken, but was there not an instance of someone being rejected here, sent to Homebrew-binary, and pinballed back to Cask?) Tangentially, I wonder if we should approach the maintainers of Homebrew and Homebrew-binary. It would be helpful to reach a consensus on the canonical location of binary packages. (The issue might be murkier than we suspect, as many formulae now use poured bottles which overlap upstream binary distributions.) (Addendum: I am not very sure about how we could sponsor Cask politely. “Excuse me, sir, I think we are just more popular; could you please drop your project and support ours instead?”) |
The issue would be complicated further if homebrew-cask does eventually become a project independent of homebrew. On the other hand, even some homebrew owners suggested homebrew-cask for a binary in at least one case. |
adidalal
removed
the
awaiting maintainer feedback
There have been a lot of cli-only app submissions, recently, and it’s clear that few know of homebrew-binary. As suggested, this documents and clarifies cases when a cask should be submitted first to hombrew-binary.