PolicyEngine / PolicyEngine/policyengine-sim-api
Move the simulation executor onto the canonical SPM bundle (policyengine 6.0.0)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1
- Forks
- 1
- Avg merge
- 10h 29m
- Merged PRs (30d)
- 7
Description
The simulation executor pins the pre-canonical bundle: policyengine==5.2.0, policyengine-core==3.30.1, policyengine-us==1.764.6, spm-calculator==0.3.1. That bundle has no measurements.spm, so runtime_spm_capability() returns None, /versions advertises no spm_capabilities entry, and every US request resolves through the legacy no-selection arm.
policyengine 6.0.0 was published to PyPI on 2026-09-15T13:37:27Z. Its bundle manifest binds the canonical SPM tuple:
policyengine-core==3.32.5policyengine-uk==2.90.2policyengine-us==2.2.1spm-calculator==1.0.0data_releases.us->populace-us-2024-spm-20260915measurements.spm-> scenarioce_trend,geography_kindcounty,county_vintage2020,forecast_content_sha2563d86d5c4c0423480e6b69b75d222ffa4a7a2639e4094df5ba2504af01be17173
Move the executor onto that bundle so the deployed worker advertises contract_version: canonical-spm-v1 with those bundle defaults.
Two things block a pin-only change:
policyengine-us2.2.1 requiresspm-calculator>=1.0.0,<=1.0.0.post1, which is unsatisfiable against the executor'sspm-calculator==0.3.1. The automatic updater (.github/scripts/update-policyengine-package.sh) does not touch that pin, so its run for 6.0.0 failed atuv lockand opened no PR (run 34976880733).BUNDLE_CONSTRAINT_FILESinsrc/modal/app.pyselects aPIP_CONSTRAINTfile by exact bundle version and raises for an unregistered one, so 6.0.0 cannot build an image until it has a reviewed calculator selection of its own.
Merging to main deploys beta and then production (simulation-deploy.yml), so the PR for this work stays a draft until a maintainer decides to release.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the dependency pins and .github/scripts/update-policyengine-package.sh, then inspect BUNDLE_CONSTRAINT_FILES in src/modal/app.py to understand the required bundle registration. Run uv lock while checking the policyengine-us and spm-calculator constraints, and review simulation-deploy.yml. Done means the executor builds on policyengine 6.0.0 and advertises the stated canonical-spm-v1 defaults; release timing remains a maintainer decision.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, python
- Domain
- backend, build-system, devops
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100