Add reusable native model package manager

[mirek190]

What changed

• Added a reusable native C++ package-management library: audiocpp_package_manager.
• Added the standalone audiocpp_model_manager executable for CLI, Docker, and headless workflows.
• Updated audiocpp_server to call the same library directly while retaining its asynchronous HTTP job API for the native WebUI.
• Kept tools/model_manager_v2.py available and supported during the migration.
• Added native catalog inspection, download/install, progress, cancellation, partial cleanup, atomic publication, removal, inventory, and conservative remote-version checks.
• Updated Windows, Linux Docker, and Nix packaging to include the standalone native manager.

Architecture

model_specs/*.json remains the editable source of truth. CMake embeds the active package catalog into the reusable library, while an explicitly supplied external catalog can still override it.

                         +-----------------------+
model_specs/*.json ----> | audiocpp_package_manager |
                         +-----------+-----------+
                                     |
                 +-------------------+-------------------+
                 |                                       |
                 v                                       v
      audiocpp_model_manager                    audiocpp_server
      CLI / Docker / headless              async HTTP API / WebUI

Python model_manager_v2.py remains available during migration.

The standalone executable exposes:

• list [--remote]
• info PACKAGE [--remote]
• install PACKAGE [--overwrite]
• clean PACKAGE
• remove PACKAGE

list and info produce machine-readable JSON. The native executable is intentionally lightweight and does not link the inference runtime.

Validation

• Native and Python catalogs both report 140 packages.
• Full loader/catalog sync passed: 49 active loaders, 47 specs, 140 packages.
• check_loader_catalog_sync.py --self-test passed.
• Native list, single-package info, unknown-package failure, and portable execution without external specs passed.
• Server installer lifecycle tests passed, including download, progress, cancellation, cleanup, shared sidecars, removal, and version-state coverage.
• CUDA Release builds passed for both audiocpp_model_manager.exe and audiocpp_server.exe.
• Windows package-script parsing passed.
• git diff --check passed.

[0xShug0]

@mirek190 I don’t think we should remove the Python model_manager_v2.py or rewrite the docs around the assumption that the native UI/server is the only model-download path.

The native manager is a good addition, but the Python manager is still a useful alternative, especially for CLI, Docker, remote, and scripted/headless workflows. It feels odd to require users to start the UI or call server management endpoints just to download a model.

I’d prefer to keep model_manager_v2.py for now and present the native manager as an additional path used by the built-in UI. Long term, I think the C++ package management logic should live in a dedicated reusable library instead of being owned by the server. The server can expose it for the native UI, but CLI, Docker, remote, and scripted/headless users should not need to start audiocpp_server just to download models.

Once there is a native standalone manager with similar list / info / install / clean coverage, then removing the Python v2 manager would make much more sense.

[mirek190]

So download manager should exist as a library available for server, cli and docker?

[0xShug0]

So download manager should exist as a library available for server, cli and docker?

For the C++-based manager, I mean making the core functionality a framework library so both the server and CLI can use it, while exposing an interface for model downloads (e.g., audiocpp_cli --download). But we don't need to do this now, as the non-UI user can just use the Python v2 manager in the repo.

[mirek190]

Updated this PR in response to the architecture feedback.

The Python v2 manager has been restored and remains supported. The native implementation is now additive and split into a reusable framework component rather than being owned by the server:

• audiocpp_package_manager contains the embedded/external catalog handling, Hugging Face transfer logic, staging, progress, cleanup, atomic install, removal, inventory, and version-state logic.
• audiocpp_model_manager provides a small standalone frontend for CLI, Docker, and headless use with list, info, install, clean, and remove commands.
• audiocpp_server links the same library directly and remains the async HTTP/WebUI adapter; it does not launch or depend on the standalone executable.
• CPU/CUDA Docker images, the Docker entrypoint, Nix packaging, and Windows portable packaging now include the standalone manager.

The dependency direction is therefore:

model_specs/*.json
        |
        v
audiocpp_package_manager
        |
        +--> audiocpp_model_manager  (CLI / Docker / headless)
        `--> audiocpp_server         (HTTP / native WebUI)

Validation completed locally:

• native/Python catalog parity: 140 packages each
• loader/catalog sync: 49 loaders, 47 specs, 140 packages
• native manager portable smoke test without external specs
• native list/info/error handling
• server download/progress/cancel/clean/remove/version lifecycle tests
• CUDA Release builds for the manager and server

The updated commit is a98b9cb.

[mirek190]

Too late - already done. :)

As I had a fully working model manager I needed only few changes so that could works for server, cli, doker.
Also old py script still works.

[mirek190]

Fixed the Nix failures in 9e500d7.

The failure was caused by the new native package-manager target calling find_package(CURL) while the Nix derivation did not expose libcurl headers or libraries. The derivation now includes curl in buildInputs.

I also corrected the install phase discovered while tracing this failure: it copied the native audiocpp_model_manager and then overwrote that executable with model_manager_v2.py. Nix now preserves both explicitly:

• audiocpp_model_manager — native standalone executable
• audiocpp_model_manager_v2.py — retained Python v2 manager during migration

Fresh CPU and Vulkan Nix checks are running now.

[0xShug0]

I can’t keep up 😂!

[mirek190]

I can’t keep up 😂!

Are you working on MiniMax audio ?

I'm asking because I already have working importation and will be testing tomorrow.

[0xShug0]

@mirek190 Yes! End to end done and do some finetuning of code now