Skip to content

Review documentation ahead of the release - #35

Open
glopesdev wants to merge 1 commit into
fix-package-metadatafrom
docs-release-sweep
Open

Review documentation ahead of the release#35
glopesdev wants to merge 1 commit into
fix-package-metadatafrom
docs-release-sweep

Conversation

@glopesdev

Copy link
Copy Markdown
Contributor

The API pages documented a fraction of what the packages export: seventy public names had no entry, including every Register* and Payload* class, HarpParseError, Subscription, DeviceModule and harp.data.read. Examples on the site reference those names, so the reader had nothing to click through to. That count is now zero.

Two smaller gaps go with it. The address-call idiom was documented only in two private metaclass docstrings, and the packaging metadata that the previous PR fixes had nothing stopping it regressing.

Documenting every public name

Two module-level directives do most of the work, ::: harp.protocol covering 58 names and ::: harp.device.core covering 24. The alternative was seventy individual ::: lines, which drift out of date the moment anything is exported or renamed, whereas a module directive stays correct by construction.

The concern with a module directive is page weight. The protocol page comes out at 131 KB with 66 anchors, against 163 KB for the device page, and the site builds in the same 3.6 seconds as before. Five names outside those two modules needed their own line, Subscription, EventHandler, DeviceModule, DeviceModuleLike and harp.data.read, and the seven per-name harp.device.core directives are removed because the module directive was rendering them a second time.

The address-call idiom

RegisterU16(0x08) and RegisterU8Array(0x10, length=16) build a one-off register for an address no schema names, which is how an out-of-schema payload is read and written. That was described nowhere public, only in two private metaclass docstrings.

The new harp-protocol section shows the two forms, uses R_UID at 16 and R_TAG at 17 as the motivating example, and states the two things easy to get wrong, that length is keyword-only and counts elements rather than bytes, and that an already-addressed register rejects the call so WhoAmI(44) raises.

The five package READMEs also gain the closing license and contribution sentence. One deviation from the house form: it links to the repository LICENSE rather than licenses.nuget.org/MIT, since a NuGet licence page is a strange destination from a PyPI project page.

A guard for the packaging metadata

tests/test_packaging.py asserts that each published package declares a readme, a license, classifiers, urls and authors, and that every declared license file matches the repository one. The first half is the defect the previous PR fixes, which would otherwise return unnoticed the next time a package is added. The second half is what makes the per-package license copies safe, since PEP 639 forbids a parent directory reference so the copies cannot be avoided, and nothing else prevents them drifting.

The license check is derived from the license-files declaration rather than a hardcoded list, so a future published package is covered automatically and harp-benchmarks, which is internal and removed from dist before publishing, is excluded without a special case.

@glopesdev glopesdev added the documentation Improvements or additions to documentation label Aug 21, 2026
Module-level directives for harp.protocol and harp.device.core give
every public name an API page entry, replacing the per-name core
directives.

The address-call idiom is now documented in the harp-protocol README,
showing how a register base with an address reaches a payload no schema
names, such as R_UID and R_TAG. The five package READMEs gain the
closing license and contribution sentence.

tests/test_packaging.py asserts that each published package declares a
readme, a license, classifiers, urls and authors, and that every
declared license file matches the repository one, since PEP 639 requires
a copy per package.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants