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
The [frames] extra caps views-frames <2.0.0 — every views-reporting environment is held on views-frames 1.x by it #91
views-reporting requests that extra (views-evaluation[frames]>=1.0.0,<3.0.0, their pyproject.toml:49). So any environment holding views-reporting resolves views-frames <2through your extra, regardless of what views-pipeline-core declares.
Why it matters now
views-frames 2.0.0 has been on PyPI since 2026-08-18. views-pipeline-core 3.3.0 widens its own ceiling to <3.0.0 (views-platform/views-pipeline-core#488, measured: full suite on 2.0.0) so views-postprocessing can move. In a reporting environment that widening delivers nothing until your extra admits 2.x. The only environments that will actually see views-frames 2.0.0 after 3.3.0 are the views-models ensembles, which install no views-reporting.
What 2.0.0 of views-frames changed (their ADR-028)
A frame's index must be a SpatioTemporalIndex (TypeError otherwise); .values is a read-only view; map_estimate refuses inf/NaN by name. If to_metric_frame only ever passes a SpatioTemporalIndex and never writes into a frame's buffer, the change is a pin edit plus your suite on 2.0.0. views-pipeline-core's whole suite passed on views-frames 2.0.0 with views-evaluation 2.0.0 beside it (2896 passed in a fresh venv), which exercises to_metric_frame on 2.0.0 through our path — evidence for your side, not proof.
Ask
Widen the extra to views-frames>=1.10.2,<3 on measurement (your suite on 1.10.2 and 2.0.0), in a MINOR. Our CHANGELOG for 3.3.0 names this cap so operators don't expect what the environment can't give.
Taken up 2026-09-19. Measured before touching anything:
Check
Result
Full suite on views-frames 2.0.0, fresh venv (views-evaluation 2.0.0 editable, dev group installed)
994 passed
Full suite on views-frames 1.10.2, the existing env
994 passed
MetricFrame saved under 1.10.2, loaded under 2.0.0
identical rows, metric set and values; timestamp stays int
Saved under 2.0.0, loaded under 1.10.2
identical
Why it is this small: this package uses one name from views-frames, FrameMetadata (plus conformance.assert_frame_envelope in tests). MetricFrame is this repo's own class and never constructs a views-frames frame, so ADR-028's SpatioTemporalIndex requirement, read-only .values and map_estimate refusals never reach it.
Plan: widen the extra to >=1.10.2,<3, add a guard that pins the extra's range and a CI probe on 2.0.0, CHANGELOG entry; then release 2.1.0 (MINOR) with the §3.2 notification to views-reporting before the tag.
Correction to the premise, found by this change's review and verified by grep on 2026-09-19: views-reporting declares its own direct views-frames>=1.10.2,<2.0.0 (their pyproject.toml line 32 on main and development, line 27 at v0.3.3), beside the views-evaluation[frames] request at line 56. So our cap was not "the only thing" holding reporting environments on 1.x, and widening our extra admits nothing there until they widen theirs. The change is still right — our cap should not exist — and the release note now states only this repo's contract: the extra no longer excludes 2.x; a consumer whose own bounds exclude it must widen those too.
Also visible in that file: views-reporting's request is now views-evaluation[frames]>=2.0.0,<3.0.0, so epic story S9 is done on their side with the floor raised.
Second measurement: full suite green on 1.10.2, 1.11.0 and 2.0.0 (999 with this change's three new tests). CI now runs the whole suite on the floor, derives the floor from pyproject.toml, and asserts the resolved version is the 2.x end. ADR-022 §7 gained a checklist line asking at every release whether a capped dependency has published outside its range.
Status 2026-09-19 — everything except the publish click is done.#92 (the widening, guards, CI legs) and #94 (release commit) merged; #95 to main; tag v2.1.0 = e01422d; draft GitHub Release created; #96 back-merged. Publishing the draft runs the suite first, then uploads.
CI on the release branch: resolved views-frames 2.0.0 on the main leg; pip check clean and the whole suite green on the 1.10.2 floor leg.
Found on the way and filed separately: #93 — our numpy <2.0.0 cap makes the wheel uninstallable from wheels on Python 3.13 and 3.14, both declared supported, and has silently frozen scipy at 1.17.x since June. C-41 re-tiered to 2. This issue closes when PyPI shows 2.1.0.
Activity
Polichinel commentedon Sep 19, 2026
views-pipeline-core 3.3.0 is on PyPI (https://github.com/views-platform/views-pipeline-core/releases/tag/3.3.0) with
views-frames <3.0.0andviews-evaluation >=2.0.0,<3.0.0. Your[frames]extra's<2cap is now the binding one in every views-reporting environment — the ask above stands.Polichinel commentedon Sep 19, 2026
Taken up 2026-09-19. Measured before touching anything:
MetricFramesaved under 1.10.2, loaded under 2.0.0timestampstaysintWhy it is this small: this package uses one name from views-frames,
FrameMetadata(plusconformance.assert_frame_envelopein tests).MetricFrameis this repo's own class and never constructs a views-frames frame, so ADR-028'sSpatioTemporalIndexrequirement, read-only.valuesandmap_estimaterefusals never reach it.Plan: widen the extra to
>=1.10.2,<3, add a guard that pins the extra's range and a CI probe on 2.0.0, CHANGELOG entry; then release 2.1.0 (MINOR) with the §3.2 notification to views-reporting before the tag.🤖 Generated with Claude Code
Polichinel commentedon Sep 19, 2026
Correction to the premise, found by this change's review and verified by grep on 2026-09-19: views-reporting declares its own direct
views-frames>=1.10.2,<2.0.0(theirpyproject.tomlline 32 onmainanddevelopment, line 27 at v0.3.3), beside theviews-evaluation[frames]request at line 56. So our cap was not "the only thing" holding reporting environments on 1.x, and widening our extra admits nothing there until they widen theirs. The change is still right — our cap should not exist — and the release note now states only this repo's contract: the extra no longer excludes 2.x; a consumer whose own bounds exclude it must widen those too.Also visible in that file: views-reporting's request is now
views-evaluation[frames]>=2.0.0,<3.0.0, so epic story S9 is done on their side with the floor raised.Second measurement: full suite green on 1.10.2, 1.11.0 and 2.0.0 (999 with this change's three new tests). CI now runs the whole suite on the floor, derives the floor from pyproject.toml, and asserts the resolved version is the 2.x end. ADR-022 §7 gained a checklist line asking at every release whether a capped dependency has published outside its range.
🤖 Generated with Claude Code
Merge pull request #92 from views-platform/story/widen-frames-extra
Merge pull request #94 from views-platform/release/2.1.0
Polichinel commentedon Sep 19, 2026
Status 2026-09-19 — everything except the publish click is done. #92 (the widening, guards, CI legs) and #94 (release commit) merged; #95 to
main; tagv2.1.0=e01422d; draft GitHub Release created; #96 back-merged. Publishing the draft runs the suite first, then uploads.CI on the release branch: resolved views-frames 2.0.0 on the main leg;
pip checkclean and the whole suite green on the 1.10.2 floor leg.Found on the way and filed separately: #93 — our numpy
<2.0.0cap makes the wheel uninstallable from wheels on Python 3.13 and 3.14, both declared supported, and has silently frozen scipy at 1.17.x since June. C-41 re-tiered to 2. This issue closes when PyPI shows 2.1.0.🤖 Generated with Claude Code