ADR-001 — Pure-stdlib Python, no third-party dependencies

  • Status: Superseded by ADR-013 (2026-08-29)

  • Date: 2026-08-29

  • Deciders: stakeholder, implementer

Context

The add-in runs inside Fusion’s embedded Python interpreter. The unrolling engine (PRD §6) needs linear algebra, and the export layer (PRD §8) needs to write PDF and DXF files. Both are problems with mature third-party libraries. The question is whether to depend on any of them.

The M0 verification spike (PRD §11) established that Fusion 2704.1.53 bundles CPython 3.14.0 whose site-packages contains only README.txt and speedtest.py. numpy, scipy, reportlab, ezdxf and PIL all fail to import.

Decision

Pure Python standard library. No third-party runtime dependencies and no compiled extensions. Development tools (pytest, ruff, mypy, sphinx, hypothesis) are permitted because they never ship in the add-in bundle.

Consequences

  • All linear algebra is hand-written, kept small in core/linalg.py.

  • PDF and DXF files are authored directly (see ADR-003).

  • CI targets Python 3.14 to match the runtime exactly.

  • The portable core (G6) carries no dependency baggage into a future FreeCAD addon.

Why this was superseded

The reasoning recorded here contained two factual errors, both corrected by direct measurement in ADR-013:

  1. It asserted that numpy “is not available and will not be vendored”, conflating infeasible with not worth it. Vendoring numpy into Fusion in fact works, at full native speed.

  2. It asserted that the performance argument for a compiled language “evaporates”. The real figure is that numpy gives roughly 11x on the Tier E relaxation.

The decision itself is unchanged — ADR-013 reaffirms pure-stdlib on corrected evidence. This ADR is superseded rather than edited because the rationale a reader relies on must not silently change (CLAUDE.md §13).