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. a dummy app which calls the Homebrew-installed CLI.

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.

[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 😉

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

[stolendata]

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's indeed a bit of a tricky build process. Currently I cannot script much for my build, and need to involve a few manual contortions that slightly change with every release and request I get through user feedback.

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

Or perhaps mpv-stolendata to maintain the usual naming scheme, if you do decide to migrate the cask.

[vitorgalvao]

It's indeed a bit of a tricky build process. Currently I cannot script much for my build, and need to involve a few manual contortions that slightly change with every release and request I get through user feedback.

Thank you for the input! That confirms it’s not something to pursue.

Or perhaps mpv-stolendata to maintain the usual naming scheme, if you do decide to migrate the cask.

It has to be stolendata-mpv because that’s the pattern we use in every other case.

[miccal]

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.

@vitorgalvao I was previously using IINA, but with the lack of updates and issues under Monterey I have followed your lead and created a custom formula to install the HEAD version that builds the app bundle.

To check for updates, I am currently comparing the output of

git ls-remote https://github.com/mpv-player/mpv.git HEAD

with the output of

brew list m-mpv --version

For example, at present:

|-> git ls-remote https://github.com/mpv-player/mpv.git HEAD
2b9d8ae8b146f459da8647360d148c54cc72bc7e	HEAD

|-> brew list m-mpv --version
m-mpv HEAD-2b9d8ae

and notice that the 2b9d8ae is the same.

Now, would you happen to know if the output of brew list m-mpv --version is always just the first seven characters of the output of git ls-remote https://github.com/mpv-player/mpv.git HEAD?

I am trying to think of a livecheck-type way to compare them.

[vitorgalvao]

created a custom formula to install the HEAD version that builds the app bundle.

Looks to be the same as mine, so we’re duplicating work. Mine is auto-updated from the main one every month or so.

To check for updates

Any reason why you check? You can simply force an update if there is one: brew install --fetch-HEAD --HEAD m-mpv. Here’s my full script:

#!/bin/bash

# Abort if mpv is running
if pgrep mpv; then
  exit 0
fi

brew unlink mpv

# May need to run twice to work:
# https://github.com/mpv-player/mpv/issues/8445
# https://github.com/mpv-player/mpv/pull/8939
if ! brew install --fetch-HEAD --HEAD 'vitorgalvao/mpv/mpv'; then
  brew install --fetch-HEAD --HEAD 'vitorgalvao/mpv/mpv'
fi

brew cleanup mpv # Remove old versions
brew link mpv

readonly old_mpv='/Applications/mpv.app'
readonly new_mpv="$(find /opt/homebrew/Cellar/mpv -name 'mpv.app')"

if [[ -n "${new_mpv}" ]]; then
  rm -rf "${old_mpv}"
  mv "${new_mpv}" "${old_mpv}"
fi

[miccal]

Looks to be the same as mine, so we’re duplicating work. Mine is auto-updated from the main one every month or so.

Yes I saw that, very nice :)

You can simply force an update if there is one: brew install --fetch-HEAD --HEAD m-mpv.

Ah nice, I did not think of running brew install --fetch-HEAD --HEAD m-mpv -- thank you.

Any reason why you check?

Mainly because I regularly run brew livecheck --installed and wanted mpv to stop showing:

|-> brew livecheck m-mpv
m-mpv : 0.33.1 ==> 0.34.0

and instead show something like:

|-> brew livecheck m-mpv
m-mpv : HEAD-2b9d8ae ==> HEAD-2b9d8ae

Thanks for taking the time to respond @vitorgalvao.

[carlocab]

It seems to me that there's a lot of interest in a source-built app bundle from the formula -- enough so that at least two maintainers have tried to maintain their own versions of the formula to do so.

This is a good enough reason for me to also build the app bundle in the Homebrew/core formula, especially if it doesn't entail additional dependencies.

I know we don't like app bundles in Homebrew/core, but remember that we don't like them just because we don't like GUIs. We don't like them because building them in formulae tends to lead to a poorer user experience. In this case, I think not building the app bundle in the formula is what leads to a poorer user experience, so I think we should start considering just building it in the formula too.

[miccal]

Thanks @carlocab, it would be great to re-add this to the mpv Formula in homebrew-core.

[vitorgalvao]

@carlocab I absolutely agree with your logic. However, there is the limitation that Homebrew formulae cannot place files outside their directory. Note how I need to move the app bundle via bash at the end. I do it so the bundle is in a predictable location so it can be associated with filetypes.

I remember a user saying they installed the formula for themselves and the cask on their wife’s computer, because she was a non-power user to whom the bundle in /Applications matters.

So the bundle building in the formula wouldn’t remove the need for a cask. But I’m not too comfortable with the status quo of a semi-official build in the cask, either. Perhaps we could do some trickery, having the cask depend on the formula then move the app bundle to the user’s appdir (assuming the bundle can work independently).

Hacky, but we already have one formula and one cask anyway, and we have control over both sides.

[SMillerDev]

Isn't there a brew linkapps for this kind of problem?

[frozenpandaman]

there's a lot of interest in a source-built app bundle from the formula

Just adding my support here. Glad to see this issue getting some more attention/discussion recently.

Was looking into this yesterday after trying to build a version of mpv.app that runs natively on M1 Macs/ARM64 (Apple Silicon). The @stolendata cask has no current plan to support this. I got it working after a long, difficult, manual process – but would love for other users of M1 machines to be able to more easily take advantage of the available native version of the app and not have it be limited to usage via the command line… and to not have to go through fiddling with custom scripts for hours trying to get stuff (which could easily be made available out-of-the-box) to build correctly.

(Also, just to point out, the formula is currently on v0.33.1 and the cask on v0.34.0. Ideally, in revisiting this whole setup, these would always be in sync.)

[vitorgalvao]

Isn't there a brew linkapps for this kind of problem?

Does it solve it? Really asking. One issue I faced way back when was that macOS didn’t see the app bundle deep in HB’s Cellar until it was manually opened once, and on every update that dance had to me performed again.

For an app that is never opened directly (always through file associations) and that can have literal daily updates (they don’t care about releases, HEAD is officially the one true version), that is a major problem.

[frozenpandaman]

brew linkapps has was deprecated a few years ago and has since been removed:

$ brew linkapps                                                  
Error: Unknown command: linkapps

[stolendata]

... The @stolendata cask has no current plan to support this. ...

It's coming. It's just that M1/M2 is a lot of money.

Also, just to point out, the formula is currently on v0.33.1 and the cask on v0.34.0. Ideally, in revisiting this whole setup, these would always be in sync.

It's tricky because of the constant flux of the many dependencies that are required to build what at least I consider a versatile product. Every release of MPV that I publish involves a lot of manual adjustments since the last release because of the long interval these days. Only a little of the work is "automatable". Linking against 6-12 months old library versions is rarely advisable. Unfortunately I have no immediately useful solution to the problem.

(Pardon for bumping against such an old comment.)

[vitorgalvao]

I’ve tried a bunch of approaches for this over the years, including custom formulae and scripts to build the app downloaded with Homebrew.

Today I thought “what if I just had a dummy app which called the Homebrew-installed CLI?” Thus mpv DUMMY. The README explains what it is. I’m waiting for an OK from the mpv devs on the use of the name and icon.

Sharing because I remember others being in the same situation. It’s not extensively tested, but barring possible issues caused by Platypus you should have no issues with it.

[miccal]

I’ve tried a bunch of approaches for this over the years, including custom formulae and scripts to build the app downloaded with Homebrew.

Today I thought “what if I just had a dummy app which called the Homebrew-installed CLI?” Thus mpv DUMMY. The README explains what it is. I’m waiting for an OK from the mpv devs on the use of the name and icon.

Sharing because I remember others being in the same situation. It’s not extensively tested, but barring possible issues caused by Platypus you should have no issues with it.

@vitorgalvao I have created a Cask for this in my tap: https://github.com/miccal/homebrew-miccal/blob/master/Casks/m-mpv.rb

However, the .app will not launch for me and I have not been able to ascertain why?

Below is my brew config in case it helps:

|-> brew config
HOMEBREW_VERSION: 3.6.20-232-g39e158f
ORIGIN: https://github.com/Homebrew/brew
HEAD: 39e158fb939dadcdf6ee0a67a0930b15f9b16b39
Last commit: 15 hours ago
Core tap origin: https://github.com/Homebrew/homebrew-core
Core tap HEAD: f14e93f215cfa6ac610cd10345ff5bec27469f0d
Core tap last commit: 62 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_AUTOREMOVE: set
HOMEBREW_CASK_OPTS: ["--no-quarantine"]
HOMEBREW_DEVELOPER: set
HOMEBREW_DISPLAY_INSTALL_TIMES: set
HOMEBREW_EDITOR: /usr/bin/open -e -W
HOMEBREW_FORCE_BREWED_CA_CERTIFICATES: set
HOMEBREW_FORCE_BREWED_CURL: set
HOMEBREW_FORCE_BREWED_GIT: set
HOMEBREW_FORCE_VENDOR_RUBY: set
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_GIT_EMAIL: [email protected]
HOMEBREW_GIT_NAME: miccal
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_NO_INSTALL_FROM_API: set
HOMEBREW_UPDATE_REPORT_ALL_FORMULAE: set
Homebrew Ruby: 2.6.8 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_1/bin/ruby
CPU: octa-core 64-bit arm_blizzard_avalanche
Clang: 14.0.0 build 1400
Git: 2.39.1 => /opt/homebrew/opt/git/bin/git
Curl: 7.87.0 => /opt/homebrew/opt/curl/bin/curl
macOS: 13.2-arm64
CLT: 14.2.0.0.1.1668646533
Xcode: N/A
Rosetta 2: false

[vitorgalvao]

However, the .app will not launch for me

Try opening a file with it (e.g. right-click → Open With) rather than just opening the app bundle. The former is meant to work while the latter is not.

(Technically the latter does work but it will close immediately and not show an icon in the dock, which looks indistinguishable from not working)

[miccal]

However, the .app will not launch for me

Try opening a file with it (e.g. right-click → Open With) rather than just opening the app bundle. The former is meant to work while the latter is not.

(Technically the latter does work but it will close immediately and not show an icon in the dock, which looks indistinguishable from not working)

Thanks @vitorgalvao, but I tried that. I have tested this on my Intel machine also, with the same result.

[vitorgalvao]

Unfortunately, I cannot reproduce at all. It works fine for me on both Intel and ARM. Your brew config does jump at me, though. What’s your output for which mpv?

[miccal]

Sorted it out, thanks @vitorgalvao.

Awesome work by the way!

[bsolar17]

In a recent PR MacOS bundles have been included in the mpv build process. Since the PR was merged after the current release 0.37.0, the current release lacks the bundles, but I assume the next release will provide them together with the other release artifacts.

From the newest mpv build actions I could download the bundle for my version of MacOS (14) and it seems to work properly although the bundle lacks a proper developer signature, so the Application needs to be confirm opened through the Security preferences pane (or maybe needs resigning).

I'm not sure whether these bundles are suitable for a cask but my understanding is that they would be the best option as they would be provided by the official source.

[vitorgalvao]

I'm not sure whether these bundles are suitable for a cask

Doesn’t look like it. From the conversation the only versions available are for macOS 12 Intel, macOS 13 Intel, and macOS 14 ARM, because that’s what’s available in GitHub runners. That’s a great first step, but not yet enough to cover all cases.

For what it’s worth, my DUMMY version has been serving me without a hitch for a year. I haven’t submitted the cask for it, though I have no quarrel if anyone wants to do it¹.

Seeing as cask_renames.json is now a thing (it wasn’t yet at the time this issue was created), renaming this cask to stolendata-mpv feels like the next course of action. PR submitted. If the official builds are ever able to support more versions, those can be the new mpv cask.

Footnotes

1. Do keep in mind it doesn’t pass the threshold, but on the other hand it’s not like it’s a hard one to maintain, I’d be surprised if another release is ever needed. ↩

[jankyupeblik]

You actually on purpose inserted the string 'stolendata' into a package name. Wow.

[bevanjkay]

The string stolendata is the name of the author of the distribution of mpv.

[jankyupeblik]

The string stolendata is the name of the author of the distribution of mpv.

Right, but nevertheless...

/nick homebrew-compromised-ransomware

Sometimes making no exceptions to the rules is just silly.

[SMillerDev]

I'm happy it made everyone aware they were installing a non-official distribution

[p-linnane]

Sometimes making no exceptions to the rules is just silly.

I find it sillier to assume that an actual malicious actor would make such a change.

[stolendata]

Right, but nevertheless...

/nick homebrew-compromised-ransomware

Sometimes making no exceptions to the rules is just silly.

Give me a break, you are being silly 😂

[frozenpandaman]

FYI changing the cask name somehow broke my Homebrew; had to manually delete the old cask (binary files, application) from all its locations and install the new one under the new name, as auto-updating didn't work. But all good now.