Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

policyengine-uk 2.102.4+ needs policyengine-core 3.32.9+, which the certified US default refuses

Open
  • Is something wrong?
#1,086 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, build-system, testing

Research direction

Start from the incomplete conflict trial at main commit 3598c38de and reproduce the listed uv lock and sync paths, then inspect the package extras and compatibility checks around microcosm-data, microcosm-frame, and us_runtime/worker_identity.py. Done means the US install paths resolve the certified policyengine-core and policyengine-us trio, UK resolves separately, and lock-level tests reject every incompatible US × UK combination.

Written by the indexing model from the issue text.

Description

Problem

From policyengine-uk 2.102.4 (2026-09-30), policyengine-uk requires policyengine-core>=3.32.9; 2.102.3 and earlier accept >=3.30.1. microcosm's workspace resolves one policyengine-core for both country extras, so uv lock --upgrade-package policyengine-uk==2.104.2 moves core 3.32.5 → 3.32.12 for the US environment too.

The certified US default that latest.json points to, populace-us-2024-spm-20260915, declares compatible_core_packages: policyengine-core ==3.32.5. With core 3.32.12 installed, microcosm.data.loader._enforce_package_compatibility on that release manifest raises:

_CertifiedPackageCompatibilityError: Certified release 'populace-us-2024-spm-20260915' is incompatible with installed policyengine-core 3.32.12; release certification requires ==3.32.5.

That is the failure #936 fixed for policyengine-us. Until it is resolved, microcosm cannot lock any policyengine-uk release from 2.102.4 on without breaking US loading.

The certified UK default, populace-uk-2023-dd68c73-4aa4b14-20260619T023711Z, already fails the same check on main. It pins policyengine-uk ==2.89.2 and policyengine-core ==3.27.1, while main locks 2.100.0 and 3.32.5.

Options

  • A. Resolve each country's core separately with [tool.uv] conflicts between the US-side and UK-side extras. A first trial on main 3598c38de (nine pairwise sets, microcosm-build/data/frame us × uk, with policyengine-uk 2.104.2) is incomplete. These parts work:

    • uv lock forks core into 3.32.5 and 3.32.12.
    • uv sync --all-packages --locked --extra us keeps core 3.32.5, policyengine-us 2.2.1 and spm-calculator 1.0.0.
    • --extra uk gets core 3.32.12.

    These do not:

    • --package microcosm-data --extra us, --package microcosm-frame --extra policyengine and --all-packages --extra policyengine still draw core 3.32.12 with policyengine-us 2.2.1.
    • --extra policyengine --extra uk installs both engines together.

    A complete version needs three more things:

    • conflict sets that cover microcosm-frame's policyengine extra;
    • a core pin on the US-side extras;
    • a lock-level test that every US install path resolves the certified trio and that every US × UK combination is refused.

    CI already installs one extra per job.

  • B. Hold policyengine-uk at 2.100.0 until a certified US release moves core.

  • C. Re-certify the US default under the newer core.

What the next policyengine-uk bump touches

This was rehearsed against policyengine-uk 2.104.2 plus PolicyEngine/policyengine-uk#2021, with the engine-uk suite run under each.

  • Uprating pins. tools/pin_uk_uprating_engine_values.py moves only the version stamp; the values are unchanged.
  • Concept mapping. Review the mapping, set engine_version, then run tools/refresh_concept_coverage.py --engine policyengine-uk.
    • 28 inputs were added since 2.100.0: alcohol and tobacco quantities, car attributes, lifetime_isa_balance, mortgage_debt and consumer_debt.
    • None matches an existing concept. fact:household.mortgage_principal is the repayment flow, already bound to mortgage_capital_repayment.
    • brma leaves the input list once PolicyEngine/policyengine-uk#2021 is in.
  • UK spine graph. tools/graph_uk_spine_fixture.py rewrites only uk_spine.json, and only the numerical_dependencies version strings change.
  • Lock hash. APPROVED_UV_LOCK_SHA256 in us_runtime/worker_identity.py follows the new lock hash.

These four are the only engine-uk failures at 2.104.2. Adding PolicyEngine/policyengine-uk#2021 does not change that list.

The eFRS parity reference (optional, and deliberately fenced)

uk/efrs_parity_reference.json still records policyengine-uk 2.89.0. Regenerating it with any later engine changes the surface: 2.89.1 adds bus_fare_spending, and 2.89.2 adds employment_sector and sic_industry_division. With 2.89.2 or later it does three things:

  1. It adds bus_fare_spending, employment_sector and sic_industry_division, taking the reference from 145 to 148 populated layers. This already happens at the lock's 2.100.0.
  2. It makes build_uk_release_input_coverage_manifest.py require a --candidate-h5 evidence refresh.
  3. With PolicyEngine/policyengine-uk#2021, it adds brma to formula_owned_persisted_overrides_included, taking that list from 13 to 14.

The refresh is purely additive. All three new columns carry signal in the certified candidate, which gives 148 required columns and 0 exclusions, and the spine produces all three. The engine-free tests still pin the frozen candidate at 2.89.0 and 145 columns (test_frozen_candidate_retains_its_original_engine_provenance and three siblings), so the re-pin should be a deliberate step, not a side effect of a bump. experiments/791-household-composition-receipts.md says it belongs with #749.

PolicyEngine/policyengine-uk#2021 needs nothing here

brma computed from the pinned enhanced FRS for 2024, 2025, 2026, 2027, 2030 and 2032 is byte-identical with and without PolicyEngine/policyengine-uk#2021. The same holds on microcosm's certified candidate for 2023, 2024, 2025, 2026, 2028 and 2030; see the comment below. microcosm's frs_brma stage sets brma for every household, so an explicit input always beats the new region default. The only brma change is the reference bookkeeping above.

Dominant language
Python
Stars
0
Forks
4
Avg merge
1d 14h
Merged PRs (30d)
106

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from PolicyEngine/microcosm

All issues in PolicyEngine/microcosm

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.