mw app dependency update fails for ImageMagick: versionRange returns 404 despite versions existing

[fritzdacat]

Description

The mw app dependency update command fails for ImageMagick (im) with a 404 error when using any version specification, even though versions exist in the API.

Steps to Reproduce

1. List available ImageMagick versions (works):

   mw app dependency versions im
   # Shows: 7.1.1-41, 7.1.1-39, 7.0.7-26, etc.

2. Try to update dependency with version range (fails):

   mw app dependency update APP_ID --set "im=~7"

3. Try with exact version (also fails):

   mw app dependency update APP_ID --set "im=7.1.1-41"

Expected Behavior

The dependency should be updated to the specified version.

Actual Behavior

GET v2/system-softwares/.../versions
Response 404 Not Found
Message: no system software versions found

Root Cause Analysis

The API returns incorrect internalVersion values for ImageMagick. When querying the versions endpoint directly (without versionRange), the internalVersion field shows:

• 71.1.41 instead of 7.1.1-41
• 70.7.26 instead of 7.0.7-26

The major version appears to be concatenated with the minor version (71 instead of 7.1), causing the semver matcher to fail.

Comparison with working software (GraphicsMagick):
GraphicsMagick has correctly formatted internalVersion values like 1.3.38, and mw app dependency update --set "gm=~1" works as expected.

Environment

• mw CLI version: 1.12.0
• OS: macOS (Darwin 24.6.0)

Workaround

None - ImageMagick cannot be configured via CLI.

Note

This appears to be an API/database issue - the internalVersion values for ImageMagick are incorrectly formatted in the backend.

[martin-helmich]

Thanks for the report.

Looks like the version filtering in the API (which the CLI also relies on) is thoroughly fucked. IIRC, the internalVersion is always supposed to be a correct SemVer (which 71.1.41 is, albeit only technically), which is why the versionRange query parameter also filters against that field. However, that only makes sense if the internalVersions are at least somewhat similar to the "presented" version number.

I think, we'll need to discuss this internally for a bit. 🤔

In the meantime, I'll see if we can come up with a client-side workaround for this. Let me think about this for a bit.