| hide |
|
|
|---|---|---|
| icon | material/hard-hat |
Project documentation for PyLD — architecture decisions, development notes, and other material that sits alongside the API reference.
Architecture Decision Records (ADRs) document the technical choices taken during development of PyLD.
!!! success inline "Use requests-cache for persistent HTTP caching in synchronous Python code"
:material-calendar-clock: 29 June 2026
Choose `requests-cache` for persistent, HTTP-aware synchronous
document-loader caching.
!!! quote inline "Document the next important project decision" When a technical choice changes PyLD's architecture, public API, dependencies, or long-term maintenance path, capture the reasoning here as an Architecture Decision Record.
ADRs are useful when a technical choice has meaningful consequences for PyLD's
architecture, public API, dependencies, or long-term maintenance. A PR
discussion is enough to establish consensus for an ADR: if the maintainers agree
with the decision and merge the PR, the ADR lands as decided.
When consensus has not been reached yet, an ADR can land as draft and be
refined in follow-up PRs. If a later decision replaces an earlier one, mark the
earlier ADR as superseded and link to the new decision.