You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rename: views-postprocessing → views-delivery (the name is a misnomer) #96
The repository / package name views-postprocessing is a misnomer. "Postprocessing" implies statistical post-forecast computation (reconciliation, calibration, draw-collapse), but this repo does none of that — those were judged mis-homed and removed (reconciliation → views_frames_reconcile; draw-collapse → views-faoapi views_frames_summarize). What it actually is, per ADR-012 (revised ontology) and docs/architecture/role_and_seams.md, is a post-forecast delivery + input-integrity layer: it enriches predictions with metadata, guards their integrity (coverage / identity / observed-range / provenance), and delivers them to a partner store.
The name misleads newcomers (and even the maintainer) into expecting a general processing library. It also undersells the actual direction: a partner-agnostic delivery layer (delivery/) with per-partner packages (unfao/ today), about to grow a second prediction store / partner (see C-33 / D-09).
Proposal
Rename to something that screams delivery, e.g. views-delivery (final name TBD). This aligns the name with ADR-012's ontology and the role-and-seams doc, and reads correctly once the repo serves multiple stores/partners.
Why this is a deliberate, NOT-urgent change
This is a published package + repo rename with a wide blast radius — it is not a quick git mv:
the PyPI package name (views-postprocessing) and the import path views_postprocessing are consumed by other repos (views-models imports views_postprocessing.unfao...; views-faoapi references the contract);
the publish workflow, CI, pins (pyproject.toml in consumers), and all docs/CICs/ADRs reference the name.
So it needs a coordinated cross-repo cutover (a deprecation shim / dual-publish window, then consumers repoint), done calmly — not during delivery-critical work.
Scope / when
Not now. Bank it; do it deliberately, ideally bundled with the multi-store rollout (C-33 / D-09) when the repo visibly becomes multi-partner and the rename is most obviously correct.
Decide the target name (views-delivery vs views-delivery-layer vs other) as part of this issue.
Refs
ADR-012 (the ontology that makes the current name wrong), docs/architecture/role_and_seams.md, C-33 (store identity hardcoded — the multi-store rollout this rename should ride with), D-09.
The blast-radius argument opens with a fact that is not true, and the deferral trigger has fired. Both point the same way: cheaper now than it looks.
1. "This is a published package + repo rename" — it is not published.curl https://pypi.org/pypi/views-postprocessing/json returns 404 and gh release list is empty, so publish_package.yml (which fires only on release: published) has never run. The PyPI half of the cost is zero today, and #125's own 2026-08-04 comment turns that into a sequencing argument in this issue's favour: publishing first would permanently squat a name already judged a misnomer.
2. The stated deferral condition has fired. It reads "bundle it with the multi-store rollout … when the repo visibly becomes multi-partner." It is: views_postprocessing/crafd/ landed in #211, tests/conftest.py declares PARTNER_PACKAGES = ("unfao", "crafd"), and docs/CLONING.md already uses crafd as its worked example.
3. One new cost this issue does not know about. The operational consumer no longer installs from @main but from a hardcoded repository URL at a pinned tag — views-models/tools/launcher/postprocessor.sh does pip install "git+https://…/views-postprocessing.git@${VIEWS_POSTPROCESSING_PIN}", currently 1.1.0. A rename breaks that URL, so views-models#364's work has to move with it. Small, but it is now a two-repo change rather than one.
The naming decision itself is unchanged and is Simon's. Nothing here argues for or against views-delivery; it argues that the cost side of the ledger is smaller than written and the timing side has arrived.
Activity
Polichinel commentedon Aug 13, 2026
The blast-radius argument opens with a fact that is not true, and the deferral trigger has fired. Both point the same way: cheaper now than it looks.
1. "This is a published package + repo rename" — it is not published.
curl https://pypi.org/pypi/views-postprocessing/jsonreturns 404 andgh release listis empty, sopublish_package.yml(which fires only onrelease: published) has never run. The PyPI half of the cost is zero today, and #125's own 2026-08-04 comment turns that into a sequencing argument in this issue's favour: publishing first would permanently squat a name already judged a misnomer.2. The stated deferral condition has fired. It reads "bundle it with the multi-store rollout … when the repo visibly becomes multi-partner." It is:
views_postprocessing/crafd/landed in #211,tests/conftest.pydeclaresPARTNER_PACKAGES = ("unfao", "crafd"), anddocs/CLONING.mdalready uses crafd as its worked example.3. One new cost this issue does not know about. The operational consumer no longer installs from
@mainbut from a hardcoded repository URL at a pinned tag —views-models/tools/launcher/postprocessor.shdoespip install "git+https://…/views-postprocessing.git@${VIEWS_POSTPROCESSING_PIN}", currently1.1.0. A rename breaks that URL, so views-models#364's work has to move with it. Small, but it is now a two-repo change rather than one.The naming decision itself is unchanged and is Simon's. Nothing here argues for or against
views-delivery; it argues that the cost side of the ledger is smaller than written and the timing side has arrived.