v0.74.0 — the media toolchain, and a pit that carries its own settings

moshcode install yt-dlp | ffmpeg | imagemagick

The three odd ones out in the tools registry: not workflow CLIs, but the media toolchain the rest of the roster is built on. cli-tools fronts all of them — dl for yt-dlp, vid for ffmpeg, img for ImageMagick — and every one of those used to answer a missing binary by telling you to go and install a system package by hand. Now the registry that installs cli-tools installs what it runs on.

Each arrives the way it actually ships, which turns out to be three different ways.

yt-dlp comes from its own releases as a self-contained PyInstaller binary — no python, no package manager — and lands in ~/.local/bin like gh/supabase/doctl. Deliberately not the distro package: extractors break whenever a site changes its markup, upstream ships a fix within days, and a distro package is frozen for the life of a release. Its upgrade is yt-dlp -U, the project's own updater. The release installer grew a bare flag for it, since the asset is the executable with no archive around it, and yt-dlp has to resolve through the version-less latest/download alias — it tags by date with no leading v, so the versioned URL would be /download/v2026.08.19/, a 404 on every release.

ffmpeg and ImageMagick exist only as distro packages. Static rebuilds are floating around, but they are unsigned third-party redistributions of somebody else's codec stack, on the two tools most likely to be pointed at a file from the internet — trading a sudo prompt for that is not a trade worth making. So they go through apt/dnf/zypper/pacman/apk, or Homebrew on macOS, and ask for root everywhere but a Mac (brew refuses to run as root, so prompting there would be a password for a step that never escalates).

Three details in that path are facts about someone else's archive rather than preference: apt refreshes its index first, because a box that has not updated in months 404s on the archive and the error names a URL instead of the problem; every manager runs non-interactively, because a continue? [Y/n] inside moshcode upgrade tools parks the whole sweep; and Fedora ships ffmpeg-free in its own repositories with the full ffmpeg only in RPM Fusion, so package names are a list tried in order rather than one string.

A tool's bin can now be a list of names. ImageMagick is why: the command is magick on version 7 and convert on 6, both current across supported distros under the same package name, so a single name reported a perfectly good install as missing on half the fleet.

Also in this release

• The pit syncs its settings automatically and carries all of them, and the trust anchor is undone (#449).
• humanDuration carries rounded minutes into the hour instead of reporting 60 (#447).

Upgrading

moshcode upgrade, or npm i -g moshcode@0.74.0.