* feat: add logos_core_get_modules_info() for generic module introspection New C API returning a JSON array describing every known module — one object each with name, path, loaded flag, direct dependencies, direct dependents, and the full embedded metadata (parsed from the plugin's declarative metadata.json; null when unreadable). ModuleInfo now caches the raw metadata JSON at discovery (via ModuleLib::LogosModule::getRawMetadataJson, no plugin instantiation), ModuleRegistry::allModulesInfo() assembles the array under the registry lock, and ModuleManager exposes it as getModulesInfoJson()/CStr. Methods/events are intentionally excluded: they require instantiating the plugin in-process, which would defeat the subprocess-isolation model for a bulk "all known modules" query. Tests: ModuleManagerTest.GetModulesInfo_* (shape, empty) and RealModuleRegistryTest.GetModulesInfo_PopulatesEmbeddedMetadata (real plugin metadata via TEST_PLUGIN). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * chore: bump logos-module to merged getRawMetadataJson (#21) Re-pin logos-module a3e288a → 2ec64c4 (master, includes #21) so the modules-info API builds against the merged getRawMetadataJson without an override. Full test suite green on this lock (181/181). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat: record module load timestamp (loaded_at) in modules-info Add ModuleInfo::loadedAt — a unix-seconds timestamp stamped by markLoaded (both overloads) and cleared to 0 by markUnloaded, so loaded_at is 0 ⟺ not loaded (reload re-stamps it). Surfaced as "loaded_at" in logos_core_get_modules_info(), letting callers derive a module's uptime as now - loaded_at (valid only while loaded). Tests: GetModulesInfo_ReturnsRichEntryPerModule now asserts loaded_at is 0 for an unloaded module and > 0 for a loaded one. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
logos-liblogos
The core runtime library for the Logos modular application platform. Provides liblogos_core (a C-API shared library) and logos_host (the module subprocess host binary).
logos-liblogos is a library. It is consumed by two frontends:
- logos-basecamp — the desktop GUI application shell
- logos-logoscore-cli — the headless CLI runtime (
logoscore)
Composed from
The runtime pulls its module-loading behaviour from a few separate repos so each piece can be swapped independently:
- logos-capability-module — issues the auth tokens that gate inter-module calls.
- logos-container — the container interface (where/how a module runs); current default is the subprocess implementation: logos-container-subprocess (one OS process per module).
- logos-module-loader — the format-loader interface (what kind of module); current default is : logos-module-loader-qt.
How to Build
The project uses a Nix flake for reproducible builds with a modular structure:
Build Complete Library (Binaries + Libraries + Headers)
# Build everything (default)
nix build
# Or explicitly
nix build '.#logos-liblogos'
nix build '.#default'
The result will include:
/bin/- Host binary (logos_host)/lib/- Core library (liblogos_core)/include/- Headers (logos_core.h, interface.h)
Build Individual Components
# Build only the binaries (outputs to /bin)
nix build '.#logos-liblogos-bin'
# Build only the libraries (outputs to /lib)
nix build '.#logos-liblogos-lib'
# Build only the headers (outputs to /include)
nix build '.#logos-liblogos-include'
# Build and run tests
nix build '.#logos-liblogos-tests'
# Build portable variant (selects portable LGX variants instead of dev)
nix build '.#portable'
Running Tests
# Build and run tests (tests run automatically during build)
nix build '.#logos-liblogos-tests'
# To run tests manually after building:
./result/bin/logos_core_tests
# Run specific tests
./result/bin/logos_core_tests --gtest_filter=AppLifecycleTest.*
# List all available tests
./result/bin/logos_core_tests --gtest_list_tests
Development Shell
# Enter development shell with all dependencies
nix develop
Note: In zsh, you need to quote targets with # to prevent glob expansion.
If you don't have flakes enabled globally, add experimental flags:
nix build '.#logos-liblogos' --extra-experimental-features 'nix-command flakes'
The compiled artifacts can be found at result/
Modular Architecture
The nix build system is organized into modular files in the /nix directory:
nix/default.nix- Common configuration (dependencies, flags, metadata)nix/build.nix- Shared build that compiles everything oncenix/bin.nix- Extracts binaries (logos_host, includes libraries for runtime linking)nix/lib.nix- Extracts libraries onlynix/include.nix- Header installationnix/tests.nix- Test suite build and execution
Note: The logos-liblogos-bin package includes both the logos_host binary and its required libraries to ensure proper runtime linking.
Local Development
To build against a local checkout of a dependency, override its input. For example the SDK:
nix build --override-input logos-cpp-sdk path:../logos-cpp-sdk
The container and format-loader abstractions live in their own repos, consumed
as inputs the same way process-stats is. To build against local checkouts:
nix build \
--override-input logos-container path:../logos-container \
--override-input logos-module-loader path:../logos-module-loader \
--override-input default-container path:../logos-container-subprocess \
--override-input default-module-loader path:../logos-module-loader-qt
(default-container / default-module-loader are the input slots for the
built-in default implementations; they point at the subprocess / qt-plugin repos.)
Library API
logos-liblogos exposes a C API via logos_core.h:
// Lifecycle
void logos_core_init(int argc, char *argv[]);
void logos_core_start();
void logos_core_cleanup();
// Module directory management
void logos_core_add_modules_dir(const char* dir);
// Instance persistence
void logos_core_set_persistence_base_path(const char* path);
// Per-module transport configuration (forwarded to the module's
// child subprocess so its LogosAPIProvider binds every listener
// instead of only the global default LocalSocket). Must be called
// before the module is loaded.
void logos_core_set_module_transports(const char* name, const char* transport_set_json);
// Inter-module access policy (per-target allowed-caller allowlists).
// Core parses it and registers the per-target restrictions with
// capability_module, which then denies token issuance for disallowed
// (caller, target) pairs. Call before logos_core_start(); NULL/"" clears.
void logos_core_set_access_policy(const char* policy_json);
// Module management
int logos_core_load_module(const char* name, bool with_dependencies);
int logos_core_unload_module(const char* name, bool with_dependents);
char* logos_core_process_module(const char* path);
void logos_core_refresh_modules();
// Dependency graph queries (forward + reverse edges; recursive walks BFS)
char** logos_core_get_module_dependencies(const char* name, bool recursive);
char** logos_core_get_module_dependents(const char* name, bool recursive);
// Module queries
char** logos_core_get_loaded_modules();
char** logos_core_get_known_modules();
// Module stats and tokens
char* logos_core_get_module_stats();
char* logos_core_get_token(const char* key);
See src/logos_core/logos_core.h for the full API.
Thread safety
Module load/unload operations (logos_core_load_module, logos_core_unload_module) are serialised internally by a single mutex. It is safe to call them concurrently from multiple threads, including rapid and repeated load/unload cycles on the same module — each call waits for its turn and the process management layer handles teardown cleanly before the next launch. logos_core_unload_module with with_dependents=true in particular holds the lock for its entire leaves-first teardown so a late-arriving load can't interleave between tearing down a dependent and its parent.
logos_core_refresh_modules is synchronised through the module registry's reader-writer lock — it is safe to call concurrently with other registry accesses, but it is not serialised against load/unload by the same mutex as above.
Read-only accessors (logos_core_get_known_modules, logos_core_get_loaded_modules) use that shared reader-writer lock and are safe to call concurrently with each other and with logos_core_refresh_modules.
Dev vs Portable Builds
The library supports two build modes controlled by the LOGOS_PORTABLE_BUILD CMake flag:
- Dev build (default): Module loading looks for LGX variants with
-devsuffix (e.g.,linux-amd64-dev). Used in Nix/development environments. - Portable build (
-DLOGOS_PORTABLE_BUILD=ON): Looks for portable variants without suffix (e.g.,linux-amd64). Used in self-contained distributed applications.
Build the portable variant with nix build '.#portable'.
Supported Platforms
- macOS (aarch64-darwin, x86_64-darwin)
- Linux (aarch64-linux, x86_64-linux)
Building with a different container or module loader
The container and format-loader are selected by which package liblogos links — not by its C++ or CMake. To use your own, build a package that:
- implements the contract interface (
LogosCore::ModuleContainerfromlogos-container, orLogosCore::ModuleFormatLoaderfromlogos-module-loader), - defines the factory symbol (
LogosCore::makeContainer()/LogosCore::makeFormatLoader()), and - ships the generic CMake config (
LogosContainerImpl/LogosFormatLoaderImpl, exposing the…::impltarget).
(Copy the structure from logos-container-subprocess / logos-module-loader-qt.)
Then point liblogos at it by overriding the input slot:
# different container
nix build '.#logos-liblogos' --override-input default-container <flake-ref>
# different format loader
nix build '.#logos-liblogos' --override-input default-module-loader <flake-ref>
<flake-ref> is e.g. github:you/your-impl or path:../your-impl; it must expose
packages.<system>.default carrying that config + factory symbol. For a permanent
default, add it as an input and set containerImpl / formatLoaderImpl in
flake.nix. Container and loader are independent — swap either or both.
Note: the format-loader package also provides the logos_host binary that
bin.nix re-exports, so a replacement loader must ship its own host binary.
Disclaimer
This repository is part of an experimental development environment. Components are under active development and may be incomplete, unstable, modified or discontinued at any time.
The software is provided for development and testing purposes only and is not intended for production use.
The code and related materials are made available on an open-source, “as-is” basis without warranties or guarantees of any kind, express or implied, including warranties of correctness, security, performance or fitness for a particular purpose. Use at your own risk.