Dependency Selection Principles

Every external dependency included in Shyft becomes part of the project’s trusted computing base (TCB). Dependency selection is therefore treated as a security decision rather than merely a development convenience.

The primary objectives are to:

  • minimize the trusted computing base;

  • reduce software supply-chain risk;

  • maximize reproducibility;

  • reduce long-term maintenance effort;

  • ensure a coherent and compatible software stack.

General Principles

Each additional dependency introduces:

  • additional attack surface;

  • additional maintenance burden;

  • additional compatibility constraints;

  • additional supply-chain risk.

Consequently, dependencies shall only be introduced when they provide substantial value that cannot reasonably be achieved using existing approved libraries or Shyft itself.

Shyft favours a small number of trusted, broadly applicable dependencies over a large collection of specialized libraries.

Dependencies shall be kept as few, explicit and accurate as possible.

Dependency Hierarchy

When selecting functionality, the following preference order shall be applied:

  1. C++ Standard Library

  2. Existing Shyft implementation

  3. Existing approved project dependencies

  4. New external dependency (requires explicit justification)

The current approved dependency hierarchy for C++ is:

C++ Standard Library
        ↓
Boost
        ↓
Armadillo
dlib
        ↓
fmt (temporary)
doctest (test-only)

The ordering reflects general project preference rather than a strict ranking between libraries serving different purposes.

Whenever functionality becomes available in a higher-priority layer, migration should be considered to reduce the overall dependency footprint.

For example:

  • std::format replacing fmt::format;

  • std::filesystem replacing Boost.Filesystem;

  • std::span replacing custom or third-party view types.

Small Functional Dependencies

Introducing an external dependency solely to obtain a small amount of functionality should generally be avoided.

If the required functionality is well-defined, stable and inexpensive to maintain, it is normally preferable to implement it as part of Shyft.

Typical examples include:

  • utility algorithms;

  • formatting helpers;

  • small mathematical functions;

  • convenience wrappers.

This reduces the trusted computing base while keeping functionality directly maintained within the project.

Trusted Dependency Sources

The preferred source of software is the package repositories provided by the supported operating system distributions.

Currently supported distributions are:

  • Arch Linux

  • Fedora

  • MSYS2

Distribution packages are preferred because they provide:

  • coherent dependency management;

  • compatibility between packages;

  • maintained build recipes;

  • continuous security monitoring;

  • cryptographically signed package repositories.

Community-maintained package definitions, such as the Arch Linux User Repository (AUR), may be used as packaging references when no official package exists.

However, release builds shall not depend on arbitrary pre-built community packages. Instead, package recipes may be reviewed and incorporated into the controlled Shyft build process.

Locally Built Dependencies

When a required dependency is unavailable from the supported distributions, or the packaged version is unsuitable for Shyft, the dependency shall be built as part of the controlled build process.

Such dependencies shall:

  • be built from a fixed git commit hash or verified upstream tag;

  • use version-controlled build recipes;

  • avoid uncontrolled downloads during the build;

  • participate in provenance and SBOM generation.

Where practical, local package builds should follow the conventions used by the target distribution.

For example, RPM-based builds may use version-controlled SPEC files derived from the Fedora package definitions with only the required modifications.

Python Dependency Policy

Python is primarily used for orchestration, scripting and user-facing APIs.

The preferred architecture is to implement reusable functionality in C++ and expose it through Shyft’s Python bindings rather than introducing additional Python package dependencies.

The preferred order is therefore:

C++ Standard Library / Shyft
        ↓
Approved C++ dependency
        ↓
Shyft Python bindings
        ↓
External Python dependency

This approach provides:

  • a single implementation shared by C++ and Python;

  • consistent behaviour across language bindings;

  • reduced Python dependency management;

  • improved portability;

  • reduced supply-chain complexity.

For example, geometry or projection functionality should generally be implemented using approved C++ libraries such as Boost.Geometry and exposed through the Python bindings rather than introducing Python packages providing equivalent functionality.

Build Tools

Compilers, linkers, build systems, documentation generators and packaging tools are considered part of the trusted computing base and are therefore subject to the same selection principles as software libraries.

Where possible, build tools shall be obtained from the supported operating system distributions. Tools not provided by the distributions shall follow the same controlled build and provenance requirements as other dependencies.

Evolution of Dependencies

The dependency hierarchy is expected to evolve over time.

As the C++ Standard Library grows, Shyft should continuously reduce its use of external libraries where practical.

Similarly, dependencies should be periodically reviewed to determine whether they remain necessary or whether functionality has become available through higher-priority layers.

The long-term objective is to continuously reduce the trusted computing base while preserving functionality, maintainability and performance.