mpvget

mpvget is a simplistic way of managing various mpv "plugins" via git.

WARNING: this is currently just a proof of concept. Do NOT use unless you wish to participate in the development.

Scope

mpvget is not (and will not be) a proper package manager. It only supports the following operations:

• Clone/fetch plugins (via git)
• Fetch updates for installed plugins
• Update mpv config to enable/disable plugins

Features such as removing unused plugins from disk or searching for plugin is not implemented yet.

Features that will not be supported:

• Managing dependencies (neither dependency on other mpv plugin or external dependency)
• Protection against rouge upstream

NOTE that many distros and/or community repos already package various mpv plugins, e.g gentoo/guru. If your distro happens to be one of them, I recommend sticking to your system package manager since it's more robust, secure and battle-tested than mpvget.

Building

• On linux

$ cc -o mpvget mpvget.c -O2 -s

• On windows (via w64devkit/mingw64)

$ cc -o mpvget mpvget.c -O2 -s -nostartfiles

Installing

Create a directory named mpvget inside your mpv's config dir. On linux it's usually ~/.config/mpv:

$ mkdir -p ~/.config/mpv/mpvget

Copy the pkg.conf file into the newly created directory:

$ cp pkg.conf ~/.config/mpv/mpvget/pkg.conf

Copy the mpvget binary somewhere in your $PATH:

$ cp mpvget /usr/local/bin/

Ensure git is installed and is accessible via $PATH. (Or you may use the --gitpath flag if you don't want git in your $PATH).

Quick Usage

Add the following in your mpv.conf (preferably at the end):

include=~~/mpvget/gen.conf

Create the file ~~/mpvget/mpvget.conf and add packages you want to install in it:

[enabled]
mfpbar = yes
CfL = lite

Run the fetch command to clone new packages and then run the update command to update the configuration file.

$ mpvget fetch
$ mpvget update

For detailed usage instruction see --help output.

Developer's Notes

This section is a mixture of developer's note and project roadmap.

No standardized directory structure

Unlike vim plugins, mpv plugins don't have any standardized directory structure. This means that mpvget (unlike something like vim-plug) cannot install arbitrary plugins, the plugin needs to be described in pkg.conf.

Having a standardized directory structure would be ideal since that would effectively make package management virtually unnecessarily - you could simply manage them via git submodules. Unfortunately this is out of scope for mpvget, since it requires active efforts from both mpv developers to come up with such a structure and the mpv community to update all existing plugins to then conform to such structure.

osd-fonts-dir

One of the design goal was to be able to enable/disable packages simply by updating ~~/mpvget/gen.conf without needing to manage any other on-disk state. Unfortunately some plugins (e.g uosc) need specific fonts and mpv (or libass rather) doesn't support multiple osd-fonts-dir paths. And so currently if the user installs such plugin it will just overwrite the user's osd-fonts-dir config. This also means you cannot have 2 different plugins that both want to install fonts enabled at the same time.

Unfortunately fixing this will probably require:

• Create symlink of the font in ~~/mpv/fonts instead of overwriting osd-fonts-dir
• Keep track of which symlink was created by mpvget so that they can safely be removed when disabling/removing a plugin.

Massive Monorepos

Using git has advantages such as being able to cheaply check for updates via git fetch. Unfortunately it also has disadvantages. For example, massive monorepos like mpv-prescalers are huge in size. So even if the user only wanted to enable one of the shaders, the entire repo needs to be pulled in. Using curl/wget on the raw file on the other hand doesn't allow for cheaply checking for updates.

Various QoL features and polish

The project is currently very rough and barely working. There's lots of quality of life features that's missing. Such as:

• Cleaning up disabled packages from disk.
• Searching for packages.
• Seeing the diff before merging new changes.

Etc, etc.