Summary
mw app create <runtime> --set im=<version> (ImageMagick) fails at the version-resolution step with a 404, so ImageMagick can't be added to a runtime app via --set. The same versions endpoint returns 200 when called directly, and creating the app with ImageMagick via the raw API works — so this is a CLI-side resolution bug.
Verified against mw 1.19.0.
Repro
mw app create php -p <project> --install-path foo --document-root / --set im=~7.1 -w
Step 1: fetching system softwares... completed
Step 2: fetching versions for im... FAILED
Error: AxiosError: Request failed with status code 404
Request GET v2/system-softwares/e015b8f3-c0bd-43c3-a8bf-2865028bbb50/versions
Response 404 Not Found ("no system software versions found")
Why this looks CLI-side
- The same endpoint returns 200 with a full list when called directly:
GET /v2/system-softwares/e015b8f3-.../versions → 6.9.4-6 … 7.1.2-15.
--set node=~22 gets past this step (Step 2 completes) — so it isn't --set in general; it's specific to (at least) im.- Installing ImageMagick via the raw API works:
POST /v2/projects/{id}/app-installations with
"systemSoftware": { "e015b8f3-…": { "systemSoftwareVersion": "<versionId>", "updatePolicy": "patchLevel" } }
→ 201, and convert (ImageMagick 7.1.2-15) is present in the app afterwards.
So ImageMagick is installable; only the CLI --set version resolution for im 404s.
Minor, likely separate (API robustness)
In that POST body, passing a version range/string (e.g. ~7.1) as systemSoftwareVersion returns 500 Internal Error instead of a 400 — the field expects the version UUID. A clear 400 (or accepting a range) would help hand-rollers.
Context
Surfaced while validating the mittwald-migrate skill. Installing image/PDF tooling (im, gm, libvips, …) as system software is the recommended alternative to a container; the --set bug currently blocks the CLI path for ImageMagick.
Summary
mw app create <runtime> --set im=<version>(ImageMagick) fails at the version-resolution step with a 404, so ImageMagick can't be added to a runtime app via--set. The same versions endpoint returns 200 when called directly, and creating the app with ImageMagick via the raw API works — so this is a CLI-side resolution bug.Verified against
mw 1.19.0.Repro
Why this looks CLI-side
GET /v2/system-softwares/e015b8f3-.../versions→6.9.4-6 … 7.1.2-15.--set node=~22gets past this step (Step 2 completes) — so it isn't--setin general; it's specific to (at least)im.POST /v2/projects/{id}/app-installationswith"systemSoftware": { "e015b8f3-…": { "systemSoftwareVersion": "<versionId>", "updatePolicy": "patchLevel" } }→ 201, and
convert(ImageMagick 7.1.2-15) is present in the app afterwards.So ImageMagick is installable; only the CLI
--setversion resolution forim404s.Minor, likely separate (API robustness)
In that POST body, passing a version range/string (e.g.
~7.1) assystemSoftwareVersionreturns 500 Internal Error instead of a 400 — the field expects the version UUID. A clear 400 (or accepting a range) would help hand-rollers.Context
Surfaced while validating the
mittwald-migrateskill. Installing image/PDF tooling (im,gm,libvips, …) as system software is the recommended alternative to a container; the--setbug currently blocks the CLI path for ImageMagick.