feat(deps): bump views-pipeline-core to 3.0.0 — six register entries close - #216
Merged
Conversation
…close
Requested by views-postprocessing#172. 3.0.0 reached PyPI 2026-08-03; our cap
excluded it, so this was a decision rather than a maintenance chore. The operator
took it.
What closes, each verified in the installed wheel rather than from the changelog
- C-73 (Tier 2) search_files_by_metadata now pages (Query.limit + Query.offset,
MAX_METADATA_PAGES). It used to return the newest of the OLDEST 25 and ship a
stale run rather than failing. get_predictions_by_metadata now raises
MetadataSearchIncomplete instead of returning [] on a failed search -- without
that, paging would have traded a false-stale answer for a false-absent one.
- C-58 (Tier 2) create_bucket is gone; a missing container fails loud BEFORE any
write, instead of silently provisioning new production storage.
- C-13 install_request_timeout() is called by pipeline-core itself, and the SDK has
a single outbound HTTP call site, so uploads, downloads and searches are all
bounded.
- C-62 geopandas, torch, shapely, pyogrio, seaborn, statsmodels, plotly gone;
155 -> 118 packages.
- C-07 appwrite and pytest declared here instead of free-ridden.
- C-44 the bump itself.
The appwrite extra is not optional despite the name
The partner managers import views_pipeline_core.modules.{appwrite,datastore}, which
import the SDK unguarded. Proven: with the SDK removed, importing the manager raises
ImportError naming the extra. Built wheel metadata carries
views-pipeline-core[appwrite], so views-models' `pip install git+...@main` gets it.
pytest was never declared here and arrived through pipeline-core, which dropped it
in 3.0.0. Without the dev group CI would have failed as "pytest: command not found".
New: tests/test_framework_contract.py
Measured with a plugin over the whole run: views_pipeline_core was imported ZERO
times by the suite. Every manager test is a source scan. So 362 green tests were
entirely orthogonal to a major framework release. This file asserts the contract --
overridden hook signatures match the base, no unimplemented abstract methods, the
MRO C-40 describes, and every inherited attribute resolves. Three mutations proven
(hook gains a parameter; MRO reordered; an undeclared inherited attribute appears).
All 13 upstream breaking changes checked against our surface; none bites. The
PredictionFrame leaf-class move was already satisfied -- we import it from
views_frames, construct positionally, never read .y_pred.
Three of my own register claims were wrong and are corrected
- Cluster M's scope line still said "Full for ... C-72 ..." three lines below the
paragraph correcting exactly that. C-72 does NOT close: its fix changes delivered
wire bytes and needs a three-repo re-vendor of the ADR-013 s10 fixture.
- C-62 claimed the bump removed most of the Dependabot surface. It did not: 29 of
31 alerts survive at unchanged versions (Pillow now via matplotlib<-pyod,
GitPython via wandb). The tree shrank; the vulnerability surface barely moved.
- C-07 said "the residual is pandas alone". Wrong twice: numpy is an undeclared
module-scope runtime import in five modules, and pandas is TYPE_CHECKING-only.
New: C-83 (Tier 2). get_queryset() swallows import errors and returns None;
declared_data_format(None) defaults to 'dataframe'; our guard then tells the
operator to set data_format: 'feature_frame' in a file that already says so. A
queryset that failed to import is indistinguishable from one declaring the wrong
format -- on the live FAO path, while someone is fixing a failed run.
Also: ruff now runs in CI (a declared linter nobody runs is a claim without a
check); README dependency table completed with pyarrow and the dev group.
370 passed / 40 xfailed / 0 failed in BOTH an isolated venv built from PyPI with
the exact resolved set and the conda editable env. ruff clean. Wire fixtures still
verify byte-for-byte; pyarrow and views-frames pins deliberately untouched.
Register 82/16/66 -> 83/17/66.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…y 815 findings The ruff CI step added in the previous commit went red immediately, and the cause is worth recording rather than just fixing. `ruff check .` was green locally and I claimed it was green, full stop. It was green on MY ruff (0.14.13). CI resolved 0.16.1 from the dev group's `>=0.6,<1.0`, and the newer release widened its default rule selection: **815 findings** on a tree nobody had touched, including DTZ005 and import-sorting rules this codebase has never been held to. Inheriting a moving default is ADR-003's forbidden inference applied to tooling: the rule set was never declared, so "ruff passes" meant "ruff passes here, today, on whatever version happens to be installed." `[tool.ruff.lint] select = ["E4", "E7", "E9", "F"]` — the classic defaults this repository has in fact been linted against throughout, which is why it is green on them. Verified with BOTH ruff 0.14.13 and 0.16.1: All checks passed. Widening beyond that is deliberate, separate work. 815 findings is a backlog, not a gate, and a gate that starts red gets switched off (ADR-014 §3). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… to walk it The ruff step went red again, this time on 745 findings inside `_siblings/views-crafdapi/tests/` — someone else's repository, checked out into the workspace so our cross-repo assertions can run. This is the THIRD tool in this repo to fall into the same hole. The coordinate-value scan walked it, and the partner-contact scan walked it and would have turned `main` red with a message asserting a file was "in this public repository" when it was in a different one. Both were fixed by scoping to `git ls-files`. A bare walk from the repo root is no longer a safe default here, and the config now says so where the next person will read it. `extend-exclude = ["_siblings"]`, plus `_siblings/` in .gitignore so a local checkout cannot commit it. Reproduced CI exactly before pushing: sibling cloned into `_siblings/`, ruff 0.16.1, run from the repo root -> All checks passed. Suite unaffected at 370 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requested by #172. views-pipeline-core 3.0.0 reached PyPI on 2026-08-03; our
<3.0.0cap excluded it, so this was a decision rather than a maintenance chore.What closes — each verified in the installed wheel, not the changelog
search_files_by_metadatanow pages (Query.limit+Query.offset,MAX_METADATA_PAGES). It used to return the newest of the oldest 25 and ship a stale run rather than failing.get_predictions_by_metadatanow raisesMetadataSearchIncompleteinstead of returning[]on a failed search — without that, paging would have traded a false-stale answer for a false-absent onecreate_bucketgone; a missing container fails loud before any write instead of silently provisioning new production storageinstall_request_timeout()is called by pipeline-core itself, and the SDK has a single outbound HTTP call site — so uploads, downloads and searches are all bounded by one chokepointappwriteandpytestdeclared here instead of free-riddenThe
appwriteextra is not optional despite the nameThe partner managers import
views_pipeline_core.modules.{appwrite,datastore}, which import the SDK unguarded. Proven by removing the SDK: the manager import raisesImportError: ... requires the optional 'appwrite' extra. Built wheel metadata carriesviews-pipeline-core[appwrite], so views-models'pip install git+…@mainresolves it.pytestwas never declared here and arrived through pipeline-core, which dropped it in 3.0.0. Without the dev group, CI would have failed as "pytest: command not found" — a dependency fault wearing a runner fault's clothes.New:
tests/test_framework_contract.pyMeasured with a plugin over the whole run:
views_pipeline_corewas imported zero times by the suite. Every manager test is a source scan, because the managers need Appwrite env and a views-models path manager to instantiate. So 362 green tests were entirely orthogonal to a major framework release — "the suite passes" was not evidence about this bump at all.This file asserts the contract instead: overridden hook signatures match the base, no unimplemented abstract methods, the MRO C-40 describes, and every inherited attribute resolves. Three mutations proven — a hook gaining a parameter, the MRO reordered, and an undeclared inherited attribute appearing.
All 13 upstream breaking changes were checked against our surface; none bites. The
PredictionFrameleaf-class move was already satisfied — we import it fromviews_frames, construct positionally, and never read.y_pred.Three of my own register claims were wrong, and are corrected here
matplotlib ← pyod, GitPython viawandb). The dependency tree shrank a lot; the vulnerability surface barely moved.numpyis an undeclared module-scope runtime import in five modules, andpandasisTYPE_CHECKING-only.New: C-83 (Tier 2) — a misdiagnosis trap on the live FAO path
get_queryset()swallows import errors and returnsNone;declared_data_format(None)defaults to'dataframe'; our guard then tells the operator to "Setdata_format: 'feature_frame'in the postprocessor's config_queryset" — a file that already says exactly that. A queryset that failed to import is indistinguishable from one declaring the wrong format, and the message lands while someone is fixing a failed run. Reproduced both ways. The fix is ours and is one branch.Verification
Wire fixtures still verify byte-for-byte;
pyarrowandviews-framespins deliberately untouched.poetry check --lockclean and byte-idempotent.Also: ruff now runs in CI — a declared linter nobody runs is a claim without a check. README dependency table completed with
pyarrowand the dev group.Register 82/16/66 → 83/17/66.