Homebrew-cask: How to deal with mpv

[vitorgalvao]

This is open to anyone to offer a suggestion.

mpv is a popular media player. It has both a formula and a cask. The former does not provide an .app, but the latter does, because we want to have a clear separation of formulae and casks and avoid shipping GUIs in formulae.

The issue is that many users want the app bundle but there’s no official source to get it. In these cases, if upstream recommends a third-party build we’ll accept it as officially sanctioned. But in this instance they’re calling the builds they link to—and that we use—“Unofficial third-party builds”.

In other words, by providing mpv as a cask, we’re not following our own rules. How should we handle this?

---

Extra notes

As a fan of mpv, the way I handle it for myself is with a custom formula, based on the Homebrew/core one with head and the commands to build the bundle. I do it not because I don’t trust the source in the cask, but because mpv releases are arbitrary and rare; all they care about is HEAD, so that’s what I want.

If you want to take this matter up with upstream, I’ll request we discuss it here first, as a few of their maintainers are extremely biased and openly hostile towards macOS. I’ve experienced some of them who were not even part of a discussion join in just to insult macOS users.

If you intend to engage with upstream on your own, please be nice and respectful. Do not take it personally and keep the focus on technical terms for the conversation to be productive. Asking them to provide compiled app bundle would be a waste of time, but if you’re willing to do the leg work—make it fit into their build system and maintain it—you may have a shot.

[ran-dall]

@vitorgalvao Doesn't macvim also have a similar problem?

What I do is build it from HEAD so that it builds the app and the binary; and then I symlink the app from the Cellar.

[vitorgalvao]

Doesn't macvim also have a similar problem?

Unless I’m missing something, the macOS builds we have in the cask are officially provided by the macvim devs.

[ran-dall]

Well, the cask version links to the instance of macvim inside of the installed app, which sometimes isn't the most up-to-date version and (if I'm not mistaken) the brew version has more features enabled than the cask version. I don't remember the exact problem that made me start building from HEAD but there was something I remember that the cask version wasn't able to deal with. That and I think the macvim app I had installed was further behind than the one on brew.

Oh, and if you have both installed, they don't like to play well with each other.

[ran-dall]

Another question...

When I look up $ brew cask info macvim, I get...

$ brew cask info macvim
macvim: 8.2.539,163 (auto_updates)
https://github.com/macvim-dev/macvim
Not installed
From: [email protected]:Homebrew/homebrew-cask.git
==> Name
MacVim
==> Artifacts
MacVim.app (App)
/Applications/MacVim.app/Contents/bin/mvim -> gview (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> gvim (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> gvimdiff (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> mview (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> mvimdiff (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> view (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> vim (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> vimdiff (Binary)
/Applications/MacVim.app/Contents/bin/mvim -> mvim (Binary)
==> Analytics
install: 965 (30 days), 3,015 (90 days), 13,362 (365 days)

I'm assuming the -> means it's symlinked.

When I look up $ brew cask info mpv...

$ brew cask info mpv
mpv: 0.32.0
https://mpv.io/
Not installed
From: [email protected]:Homebrew/homebrew-cask.git
==> Name
mpv
==> Artifacts
mpv.app (App)
/Applications/mpv.app/Contents/MacOS/mpv (Binary)
documentation/man/mpv.1 (Manpage)
==> Analytics
install: 842 (30 days), 2,818 (90 days), 14,220 (365 days)

So is the mpv Binary not symlinked?

[vitorgalvao]

Those are different matters, though. What’s important to this issue is that we’re distributing a cask from a source that upstream presumably doesn’t check. We have no idea if they know and trust the person who makes the builds or not.

Upstream not providing regular tags is their problem. Us linking to unofficial software is ours.

[ran-dall]

Understood, my mistake, but now I see the dilemma.

[miccal]

@ran-dall to answer one of your questions, the reason the output for macvim is different than for mpv in regards to the binaries is because macvim uses target: while mpv does not.

@vitorgalvao FYI mpv's installation page now also has a link for nightly builds which will be much more up-to-date.

My suggestion would be to call the current mpv cask stolendata-mpv, to make it clear it is not an "official" build from the mpv developers, and which sort-of follows the rules.

It should also be noted that homebrew-core still has a few formula that build an .app bundle -- for example, wxmaxima (which I use) -- perhaps we can suggest that they re-instate the .app to the mpv formula?

[vitorgalvao]

FYI mpv's installation page now also has a link for nightly builds which will be much more up-to-date.

But that’s just another random user who runs their script who knows when. Not a better solution for me than my formula, which rebuilds every day without my intervention.

My suggestion would be to call the current mpv cask stolendata-mpv, to make it clear it is not an "official" build from the mpv developers, and which sort-of follows the rules.

That’s the best option I can think of as well, but I’m not happy with it.

It should also be noted that homebrew-core still has a few formula that build an .app bundle

True, but the goal is to eventually reduce those too.

perhaps we can suggest that they re-instate the .app to the mpv formula?

That would be a step backwards, regarding Homebrew/core goals, and was already discussed.

[miccal]

Idea out of left-field -- how about a cask file with a depends_on formula: 'mpv' and [email protected] and an installer script: that builds the .app?

I realise this would not be easy since the mpv formula is bottled, but ... ?

[miccal]

Or, @vitorgalvao _you_ could be the third-party that provides the .app -- as third-parties go, you would be _the_ trusted third party as far as the users of homebrew-cask are concerned :wink:

[neeldug]

Solely reading from the docs here, but it seems to me that any unofficial builds shouldn't be held in the main cask repository, so perhaps it could get hosted on the unofficial repository, specifically as it states in the contribution guide. However, I'm unopposed to @miccal 's first idea for an installer script that builds the .app.

[vitorgalvao]

Idea out of left-field

Smart idea, but I have no idea if it’s feasible at all. I suspect it might not be without bending over backwards.

Or, @vitorgalvao _you_ could be the third-party that provides the .app

Thought about that as well, but it’s not as simple as compiling from the formula and distributing the bundle. I’ve tried that (by moving the bundle to a VM) but it didn’t work. If I had a script to do it properly, I’d be up for it.

it seems to me that any unofficial builds shouldn't be held in the main cask repository

Correct, hence this issue.

so perhaps it could get hosted on the unofficial repository

That doesn’t really get used much and equates to “just remove it”; I’d like to explore better options.

[miccal]

Idea out of left-field -- how about a cask file with a depends_on formula: 'mpv' and [email protected] and an installer script: that builds the .app?

I realise this would not be easy since the mpv formula is bottled, but ... ?

This is not really feasible without building mpv itself from source.

So I would suggest the following:

• Re-name the current mpv cask to stolendata-mpv.

• @vitorgalvao change your tap name and formula name to mpv-bundle or something like that, and update your README.md with more detail.

• Have your tap added to the Interesting Taps & Forks documentation so it appears in docs.brew.sh -- there is already a precedent for this with FFmpeg.