Skip to content

The [frames] extra caps views-frames <2.0.0 — every views-reporting environment is held on views-frames 1.x by it #91

Open

Description

@Polichinel

Filed from views-pipeline-core's 3.3.0 range review (our register C-330). Reported, not patched — this is your repo.

What

views-evaluation 2.0.0's metadata (PyPI, read 2026-09-19):

views-frames<2,>=1.10.2; extra == "frames"

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 <2 through 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.

Activity

  1. Polichinel commented on Sep 19, 2026

    @Polichinel
    CollaboratorAuthor

    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.0 and views-evaluation >=2.0.0,<3.0.0. Your [frames] extra's <2 cap is now the binding one in every views-reporting environment — the ask above stands.

  2. added
    storyA single, independently implementable and reviewable unit of an epic
    risk-registerOpens, closes or reconciles entries in reports/technical_risk_register.md
    on Sep 19, 2026
  3. Polichinel commented on Sep 19, 2026

    @Polichinel
    CollaboratorAuthor

    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.

    🤖 Generated with Claude Code

  4. Polichinel commented on Sep 19, 2026

    @Polichinel
    CollaboratorAuthor

    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.

    🤖 Generated with Claude Code

  5. added 2 commits that reference this issue on Sep 19, 2026
  6. Polichinel commented on Sep 19, 2026

    @Polichinel
    CollaboratorAuthor

    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.

    🤖 Generated with Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    implementationCode changerisk-registerOpens, closes or reconciles entries in reports/technical_risk_register.mdstoryA single, independently implementable and reviewable unit of an epic

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions