Skip to content
Librux Runtime Kernel for Robotics development
Librux Runtime Kernel for Robotics development

    Package Layout

    This page describes the public source checkout and the installed runtime layout.

    Public Source Checkout

    The published source surface is split by role.

    • librux - entry repository with install.sh, librux.repos, and release metadata.
    • librux-sdk - Python/C++ SDK source, public specs, C ABI headers, guided tutorials, runnable transport tutorials, managed package tutorials, and benchmark runners.
    • librux-docs - documentation source for the published docs site.
    • published docs site - user-facing documentation.

    The public checkout focuses on SDKs, tutorials, benchmarks, specs, and docs. Runtime implementation binaries are installed through the installer. librux-demo is a separate robotics application demo repository, not a source tree exported by the core release pipeline.

    Installed Runtime Layout

    The published installer places runtime artifacts under the selected prefix, normally /opt/librux.

    • <prefix>/runtime/bin - user-facing runtime CLIs such as librux, librux-control, librux-config, librux-package, librux-launch, librux-subsystem, librux-resourced, librux-doctor, and librux-timesync.
    • <prefix>/runtime/lib - native runtime libraries used by the SDKs and tutorials.
    • <prefix>/runtime/config.yaml - installed runtime config.
    • <prefix>/runtime/spec - installed fallback copy of public specs.
    • <prefix>/runtime/frontend - packaged Web Console frontend assets, when present in the target bundle.
    • <prefix>/sdk/python - platform-specific Python wheel payloads.
    • <prefix>/sdk/cpp - installed C++ SDK payload.
    • <prefix>/tutorials - installed guided tutorial source and runnable tutorial fixtures.
    • <prefix>/benchmarks - installed benchmark runners for transport and timing measurement.
    • <prefix>/licenses - runtime EULA, open-source license documents, third-party notices, and download/install data notice.
    • <prefix>/systemd - Librux service unit sources linked from /etc/systemd/system.
    • <prefix>/var - Librux-owned state, logs, and service home directories.
    • <prefix>/var/lib/packages - managed package registry and unpacked packages for product installs. The system service helper prepares this path for the non-root librux-control.service user.
    • <prefix>/env.sh - shell helper that exports LIBRUX_PREFIX, LIBRUX_RUNTIME_ROOT, LIBRUX_SPEC_ROOT, and related paths.
    • <prefix>/bin/librux-uninstall - uninstaller for service links and the selected prefix.

    Top-level entry points point into the runtime tree.

    • <prefix>/bin -> <prefix>/runtime/bin
    • <prefix>/spec -> <prefix>/runtime/spec
    • <prefix>/config.yaml -> <prefix>/runtime/config.yaml

    SDK Notes

    Python SDK metadata lives in sdk/python/pyproject.toml. The source package is Apache-2.0 and can be installed from a public checkout with this command.

    python3 -m venv .venv
. .venv/bin/activate
. /opt/librux/env.sh
pip install -e sdk/python

    Python wheel outputs are platform-specific but CPython ABI-independent (py3-none-<platform>) because the Rust core library is packaged as data rather than as a CPython extension module. Use the editable source install path above when working from a public checkout or when the active Python environment needs to build directly from source.

    The installed-user binary SDK surface is Python and C++. Rust is an internal runtime implementation language rather than a primary public SDK surface.

    Public Specs

    Public loaders resolve specs from external roots first.

    • LIBRUX_SPEC_PATH, when set
    • LIBRUX_SPEC_ROOT, normally from <prefix>/env.sh
    • installed fallback roots such as <prefix>/spec
    • packaged fallback specs inside the Python SDK

    This lets users overlay custom YAML specs while keeping the installed public spec tree available as a fallback.

    Source Boundary

    The installed tree is sufficient for normal tutorial and benchmark use. Public source checkouts are still the supported editable source surface for SDK changes, advanced benchmark matrix tooling, demos, specs, and docs. Runtime binaries are installed through the installer rather than built by ordinary application users.