Dario Gabriel LipicarandClaude Opus 5
c502fcc991
The AVAILABLE VERSIONS column listed every release inline, which pushed the table to 117 columns and wrapped every row -- blockchain_module alone carries seven versions. Search now shows the newest and `(+N)` for the rest, which fits 99 columns. The full list moves to `package show NAME`, on an `available:` line. That takes a catalog lookup, and the same lookup closes a related gap: `show` used to refuse anything not installed, which is exactly the package you ask about after a search. It now answers from the catalog and says `installed: no`; PACKAGE_NOT_FOUND is raised only when the name is in neither place. `--json` for an installed package is unchanged, and skips the extra call. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
logos-logoscore-cli
The headless CLI runtime for the Logos modular
application platform. It loads Logos modules — Qt plugins and Qt-free
universal / cdylib ones alike — and lets you call their methods from the
command line, no GUI needed.
This repo is one of two frontends for logos-liblogos:
- logos-logoscore-cli (this repo) — headless CLI runtime for scripting, testing, and headless deployments
- logos-basecamp — the desktop GUI application shell
Two binaries
| Documentation | ||
|---|---|---|
logoscore |
The tool that exists today. Commands, flags, config format and ~/.logoscore are unchanged. Keep using it. |
docs/logoscore.md |
logosctl |
logoscore + lgpd + lgpm merged into one, with package management built in. New surface, own ~/.logosctl session directory. Being validated; not yet the default. |
docs/logosctl.md |
They share the runtime but no state, so a logosctl session cannot disturb a
logoscore deployment. They are built from separate flake outputs and released
as separate artifacts. logoscore will be removed only once logosctl has been
properly validated in real use.
Everything below applies to both. For what each tool actually does — commands, configuration, authentication, transports — follow the links above.
How to Build
Using Nix (Recommended)
The two binaries have separate flake outputs. cli is logoscore, ctl
is logosctl, and each ships only its own binary — so nix build with no
target, and anything already pointing at .#cli, still gets logoscore
exactly as before.
| Output | Binary | |
|---|---|---|
.#cli (default) |
logoscore |
dev build |
.#cli-bundle-dir |
logoscore |
portable, self-contained directory |
.#cli-appimage |
logoscore |
portable, single-file AppImage (Linux) |
.#ctl |
logosctl |
dev build |
.#ctl-bundle-dir |
logosctl |
portable, self-contained directory |
.#ctl-appimage |
logosctl |
portable, single-file AppImage (Linux) |
Both come in two flavors: a dev build for local iteration and a
portable build for distribution. The dev build links against dev
logos-liblogos and works with dev modules; the portable build is
self-contained and works with portable modules — which is what the public
catalog ships, so installing from the catalog needs the portable bundle.
Installing a locally built .lgx is the mirror image: a nix module build
produces a -dev variant, so the dev build is the one that takes it. See
installing a local .lgx.
Dev Build
A standard Nix derivation whose dependencies live in /nix/store. It is the fastest way to iterate during development but is not portable — it only runs on the machine that built it. It works with dev modules: those produced by a local module nix build, or installed by the package manager's dev build.
nix build # logoscore (dev) — same as '.#cli'
nix build '.#ctl' # logosctl (dev)
./result/bin/logoscore --help
Portable Builds
Portable builds are fully self-contained — no /nix/store references at runtime. They work with portable modules: releases from logos-modules, or modules installed by the package manager's portable build.
| Output | Platform | Format |
|---|---|---|
cli-bundle-dir / ctl-bundle-dir |
Linux, macOS | Self-contained flat directory with bin/, lib/, and modules/ |
cli-appimage / ctl-appimage |
Linux | Single-file .AppImage executable |
Self-contained directory bundle (all platforms)
nix build '.#cli-bundle-dir'
./result/bin/logoscore --help
Linux AppImage (Linux only)
nix build '.#ctl-appimage'
./result/logosctl.AppImage --help
Development Shell
nix develop
Note: In zsh, quote targets containing # to prevent glob expansion (e.g., '.#cli').
If you don't have flakes enabled globally:
nix build --extra-experimental-features 'nix-command flakes'
Running Tests
Each binary has its own suite, in its own derivation, so nix builds them
concurrently. tests runs both.
| Check | Covers |
|---|---|
.#checks.<system>.tests |
both — this is what CI runs |
.#checks.<system>.tests-logosctl |
unit + CLI + integration for logosctl |
.#checks.<system>.tests-logoscore |
CLI + integration for logoscore |
The logoscore suite is a deliberate duplicate of the logosctl one, frozen
against logoscore's surface. It exists so that changes to the shared runtime
cannot regress the tool people are actually using, and it gets deleted along
with the binary.
# Both suites
nix build '.#checks.aarch64-darwin.tests'
# One suite, and its binaries, for local iteration
nix build '.#tests'
./result/bin/cli_tests
./result/bin/cli_tests --gtest_filter=CLITest.*
# Or via nix checks
nix flake check
Dependency Resolution
When loading modules, both binaries automatically resolve and load transitive dependencies in the correct order. For example, if logos_irc depends on waku_module and chat, loading logos_irc alone is equivalent to loading waku_module,chat,logos_irc.
Supported Platforms
- macOS (aarch64-darwin, x86_64-darwin)
- Linux (aarch64-linux, x86_64-linux)