podman-compose and docker-compose aren't discovered the same way by `podman compose` - verified live (a fake-binary test reading podman's own provider-search error output) that docker-compose is searched for by exact path across a fixed list of CLI-plugin directories, while podman-compose is instead looked up as a plain command on $PATH. This package installs to /usr/local/bin/podman-compose accordingly, not under any cli-plugins/ directory. Unlike docker-compose (a single static Go binary), podman-compose is a Python script with two runtime dependencies neither of which ship with Unraid's own Python3 - PyYAML and python-dotenv, vendored here as plain pure-Python source (no C extension build; PyYAML's own fallback handles its optional C accelerator being absent). Verified end-to-end on a real host: with the previous docker-compose binary temporarily moved aside to confirm podman-compose was actually the one invoked, `podman compose up/ps/down` ran a real compose project correctly, including a live HTTP check against the started service. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
packages/podman-compose/
Pinned versions: see PODMAN_COMPOSE_VERSION/PYYAML_VERSION/
PYTHON_DOTENV_VERSION in versions.env.
podman compose (backing webui/plugins/podman/ajax/compose.php, the
WebUI's Compose panel) has no compose implementation of its own — it
needs an external "compose provider" command. This project previously
vendored docker/compose (the Go CLI-plugin binary) for that role;
this package replaces it with podman-compose instead.
The two aren't discovered the same way — verified live against a real
podman install (placing a fake executable and reading podman's own
provider-search error output): docker-compose is searched for by exact
path across a fixed list of CLI-plugin directories, while podman-compose
is looked up as a plain command on $PATH. That's why this package
installs to /usr/local/bin/podman-compose rather than under any
cli-plugins/ directory.
Unlike docker-compose, podman-compose is a single Python script, not a
compiled binary. Unraid ships Python3 itself but neither of its two
runtime dependencies, so this package also vendors:
PyYAML— only the pure-Pythonyaml/package, not the_yamlC extension (which would need libyaml plus a compiler).yaml/__init__.pyfalls back gracefully when the C accelerator isn't importable, so the pure-Python source is sufficient for what podman-compose needs from it.python-dotenv— pure Python throughout, no C extensions at all.
Verified end-to-end on a real Unraid host: the vendored bundle correctly
runs podman compose up/ps/down against a real compose project
(with the pre-existing docker-compose binary temporarily moved aside
to confirm podman-compose was the one actually being invoked, not a
leftover), including a live HTTP check against the started service.