maggesandClaude Sonnet 5
18b414d7b5
Every other packages/*/*.SlackBuild is 755 — this one was created at 644
(likely from how it was originally written to disk), so
scripts/build-packages.sh's own executability check correctly refused to
run it ("No SlackBuild found/executable for 'podman-compose'"), failing
the whole build — confirmed from a real Gitea Actions run's log
(build-packages.yml run 110).
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.