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
Stale 'not on PyPI' references after the September publishes — #410, #282, C-50, #63, one report #468
Three platform packages this repo depends on were published to PyPI between 28 July and 15 September,
and a set of documents and register entries still describe them as unpublished. None of it changes
what runs; all of it misleads the next reader. One ticket, one PR.
What is now true (verified against PyPI 2026-09-15)
§0 publish table: views-postprocessing — not on PyPI, views-hydranet — not on PyPI
pin table (~line 107): views-hydranet >=0.1.0,<1.0.0 (8 models) ❌ not on PyPI — the pin is
now ~=0.1.0 and it resolves; views-postprocessing ❌ not on PyPI
§0 table: views-baseline 1.0.1 — 1.0.2 now, and 1.0.1 was the broken one
"Two blockers remain for 'pin to released versions'" — hydranet is resolved; only the FAO
launcher's git+…@main install remains, and "not on PyPI" is no longer the reason for it
"does not do" list (~line 186): "Resolve views-hydranet or views-postprocessing publication"
reports/conda_to_uv_migration_investigation.md — lines 20, 307, 348, 469, 510, 870–871, 1536
say views-baseline / views-hydranet are not on PyPI and propose git+ dependencies for them. It is a
dated investigation and line 1536 already hedges "as of this writing … check PyPI". One line at the
top noting the publishes, with dates, is enough; do not edit the body.
Not in scope
The FAO launcher's git+…@main install of views-postprocessing. Real, separate, and a moving
branch pointer is the problem there — not PyPI availability. Belongs with views-pipeline-core#222.
CI installing views-hydranet so test_roster_configs_load.py stops skipping. That is a workflow
change, not a doc change; its own issue.
Three platform packages this repo depends on were published to PyPI between 28 July and 15 September,
and a set of documents and register entries still describe them as unpublished. None of it changes
what runs; all of it misleads the next reader. One ticket, one PR.
What is now true (verified against PyPI 2026-09-15)
~=0.1.0(#462)git+…@main, separately)All 8 HydraNet models were verified to install from real PyPI in a clean venv and import
HydranetManageron 2026-09-15.What still says otherwise
Living documents — fix these:
PR Release: development → main (442 commits) — G5 of the runbook, HOLD at G4b #410 (the
development → mainrelease), section "What this release explicitly does not do":Both are published. Also lists "fix the views-r2darts2 three-way split (C-115)" — done in fix(#317): one satisfiable views-r2darts2 spec across all 31 models #461.
Issue views-models release runbook — G0 at 5/6, blocked by #336 #282 (the release runbook):
views-postprocessing — not on PyPI,views-hydranet — not on PyPIviews-hydranet >=0.1.0,<1.0.0 (8 models) ❌ not on PyPI— the pin isnow
~=0.1.0and it resolves;views-postprocessing ❌ not on PyPIviews-r2darts2 — three specs across 31 models — see C-115— one spec since fix(#317): one satisfiable views-r2darts2 spec across all 31 models #461views-baseline 1.0.1— 1.0.2 now, and 1.0.1 was the broken onelauncher's
git+…@maininstall remains, and "not on PyPI" is no longer the reason for itreports/technical_risk_register.mdC-50 — "views-baseline not published to PyPI", StatusOpen. Stale since 2026-07-28. Should be Resolved with the publish date and a pointer to fix(#459): adopt views-baseline 1.0.2 — raise the floor ×37, and make the smoke test able to fail #460.
Issue chore: verify C-42 resolution and track views-baseline PyPI publish (C-50) #63 — tracks C-42 / C-50, the baseline publish. Closable once C-50 is marked.
Historical record — mark, don't rewrite:
reports/conda_to_uv_migration_investigation.md— lines 20, 307, 348, 469, 510, 870–871, 1536say views-baseline / views-hydranet are not on PyPI and propose
git+dependencies for them. It is adated investigation and line 1536 already hedges "as of this writing … check PyPI". One line at the
top noting the publishes, with dates, is enough; do not edit the body.
Not in scope
git+…@maininstall of views-postprocessing. Real, separate, and a movingbranch pointer is the problem there — not PyPI availability. Belongs with views-pipeline-core#222.
test_roster_configs_load.pystops skipping. That is a workflowchange, not a doc change; its own issue.
Acceptance
models/*/requirements.txtondevelopmentgrep -rn "not on PyPI" docs/ reports/ README.mdreturns only lines that are explicitly dated history