homebrew-cask
homebrew-cask copied to clipboard
Homebrew
How to deal with mpv
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.
@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.
Doesn't
macvimalso have a similar problem?
Unless I’m missing something, the macOS builds we have in the cask are officially provided by the macvim devs.
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.
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?
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 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?
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
mpvcaskstolendata-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
.appto thempvformula?
That would be a step backwards, regarding Homebrew/core goals, and was already discussed.
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 ... ?
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:
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.
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.
Idea out of left-field -- how about a cask file with a
depends_on formula: 'mpv'and[email protected]and aninstaller script:that builds the.app?I realise this would not be easy since the
mpvformula is bottled, but ... ?
This is not really feasible without building mpv itself from source.
So I would suggest the following:
-
Re-name the current
mpvcask tostolendata-mpv. -
@vitorgalvao change your tap name and formula name to
mpv-bundleor something like that, and update yourREADME.mdwith 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.
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.
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-stolendatato 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.
As a fan of mpv, the way I handle it for myself is with a custom formula, based on the Homebrew/core one with
headand 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.
created a custom formula to install the HEAD version that builds the
appbundle.
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
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.
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.
Thanks @carlocab, it would be great to re-add this to the mpv Formula in homebrew-core.
@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.
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.)
Isn't there a
brew linkappsfor 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.
brew linkapps has was deprecated a few years ago and has since been removed:
$ brew linkapps
Error: Unknown command: linkapps
... 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.)
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.
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
However, the
.appwill 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)
However, the
.appwill not launch for meTry 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.