packaging

17 beliefs (15 IN, 2 OUT)

The packaging topic covers how ftl-reasons is structured, distributed, and installed as a Python package. The central design principle is zero runtime dependencies: the core reasons_lib package runs entirely on Python's standard library, with an empty dependencies list in pyproject.toml (zero-runtime-dependencies, zero-runtime-deps, ftl-reasons-zero-runtime-deps). This constraint is enforced not just at the packaging metadata level but also in the implementation itself — the Network class, which is the engine of the truth maintenance system, imports only stdlib modules like collections.deque and datetime alongside internal dataclasses (network-has-zero-external-dependencies, network-no-external-deps). Together these layers eliminate supply-chain risk and simplify deployment (project-has-zero-external-coupling).

Optional functionality is available through install extras that map one-to-one to specific modules: the pg extra gates reasons_lib/pg.py for PostgreSQL support, cluster gates reasons_lib/cluster.py, and test-pg is a superset combining pg and test dependencies (extras-map-one-to-one-to-modules). This design means users who only need the core TMS backed by SQLite install nothing beyond the standard library, while those needing PostgreSQL or clustering opt in explicitly. The pip-installable name is ftl-reasons while the importable package is reasons_lib, a deliberate decoupling (package-name-split). Only the reasons_lib package ships in built distributions — tests, entries, reviews, and knowledge-base artifacts are excluded (only-reasons-lib-is-distributed, only-reasons-lib-packaged).

The project requires Python 3.10 or higher, which enables use of structural pattern matching and the X | Y union type syntax throughout the codebase (python-310-floor, python-310-minimum, python-version-floor-3-10). Versioning is managed manually with a static declaration in pyproject.toml — there is no dynamic version plugin or SCM-based versioning (version-is-manual). The project was renamed from rms to reasons at version 0.3.0, motivated by a measured 5 percentage-point improvement in LLM accuracy identified through ablation study (rename-from-rms-at-0.3.0).

Two beliefs are currently OUT (retracted): system-efficiency-spans-packaging-and-runtime and system-resource-footprint-is-minimal-at-all-phases. Both attempted to unify packaging-level concerns like zero dependencies with runtime concerns like lazy loading and token estimation into single cross-cutting claims. Their retraction suggests that the knowledge base prefers to keep packaging constraints and runtime optimization as separate, independently justified topics rather than conflating them into broader system-efficiency narratives.