Bump bundled US manifest to policyengine-us 1.653.3#284
Merged
Conversation
Brings the certified US bundle up from 1.647.0 to 1.653.3 (latest on PyPI that imports cleanly against the current policyengine-core>=3.25.0 pin — 1.637-1.645 all fail parameter validation at class-creation). The underlying dataset stays at policyengine-us-data 1.73.0 (the latest US data release tagged on Hugging Face; 1.83.x exists only on main branch as of 2026-04-18 and has no corresponding rev). Certification basis moves from `exact_build_model_version` to `matching_data_build_fingerprint`, with `built_with_model_version` recording the 1.647.0 that actually produced 1.73.0. Also bumps `bundle_id` and `policyengine_version` on both us.json and uk.json to 3.5.0 so the bundled manifests match the current package version. Unblocks downstream projects (e.g., policybench) that want to use `policyengine.py` with the latest model version through the certified bundle path rather than falling back to `policyengine_us` imports. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the hand-rolled == equality check in _specifier_matches with packaging.specifiers.SpecifierSet. A data release manifest can now declare compatibility with a range of model versions (e.g. >=1.637.0,<2.0.0) instead of a single pin; certify_data_release_compatibility accepts any runtime version that satisfies the specifier. Adds packaging>=23.0 as a direct dependency (already transitively installed via pandas). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
MaxGhenis
added a commit
to PolicyEngine/policyengine-us-data
that referenced
this pull request
Apr 18, 2026
`build_release_manifest` now takes `additional_compatible_specifiers`: a list of PEP 440 specifier strings that extend the `compatible_model_packages` list beyond the single `==<build_version>` entry it emits by default. Motivation: when the `data_build_fingerprint` is stable across a range of `policyengine-us` versions, the data package can declare compatibility without forcing downstream consumers (policyengine.py, policybench) to rebuild the dataset for every model patch release. Without this, the published release manifest lists only the exact build-time model version, which in practice is sometimes a broken pin (1.637.0 fails parameter validation against current policyengine-core). The policyengine.py side that consumes these specifiers was extended in PolicyEngine/policyengine.py#284 to handle full PEP 440 specifiers via packaging.specifiers.SpecifierSet. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
MaxGhenis
added a commit
to PolicyEngine/policyengine-us-data
that referenced
this pull request
May 5, 2026
) `build_release_manifest` now takes `additional_compatible_specifiers`: a list of PEP 440 specifier strings that extend the `compatible_model_packages` list beyond the single `==<build_version>` entry it emits by default. Motivation: when the `data_build_fingerprint` is stable across a range of `policyengine-us` versions, the data package can declare compatibility without forcing downstream consumers (policyengine.py, policybench) to rebuild the dataset for every model patch release. Without this, the published release manifest lists only the exact build-time model version, which in practice is sometimes a broken pin (1.637.0 fails parameter validation against current policyengine-core). The policyengine.py side that consumes these specifiers was extended in PolicyEngine/policyengine.py#284 to handle full PEP 440 specifiers via packaging.specifiers.SpecifierSet. Co-authored-by: Claude Opus 4.7 (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
1 participant
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.
Summary
policyengine-us==1.647.0to1.653.3(latest PyPI version that imports cleanly againstpolicyengine-core>=3.25.0)policyengine-us-data==1.73.0(latest tagged revision on Hugging Face); certification moves fromexact_build_model_versiontomatching_data_build_fingerprint, withbuilt_with_model_versionrecording the 1.647.0 that produced the databundle_idandpolicyengine_versionon bothus.jsonanduk.jsonto 3.5.0 to match the current package versionWhy
Unblocks downstream projects that want the latest
policyengine-usthrough the certified bundle path.policybenchin particular is migrating from directpolicyengine_usimports topolicyengine.pyand needs a recent model pin.Versions 1.637 – 1.645 fail parameter validation at class-creation time against current
policyengine-core, so even though the HF data release manifest names 1.637.0 as its build-time model, we cannot pin it in a working bundle. 1.650.0 is the earliest that imports; 1.653.3 is latest.Test plan
pytest tests/test_release_manifests.py tests/test_trace_tro.py tests/test_us_regions.py tests/test_models.py tests/test_results.py tests/test_manifest_version_mismatch.py— 127 passed locallyruff check .+ruff format --check .— cleanKnown limitations
matching_data_build_fingerprintis declared without an actual fingerprint value becausepolicyengine-usdoes not yet exposedata_build_fingerprintat runtime. The runtime fallback incertify_data_release_compatibilityaccepts the bundled certification when the HF manifest is unreachable (the current 1.73.0 path) so this is not a regression; it's documented as future work.🤖 Generated with Claude Code