Implement registry version check script

[thomashoneyman]

Closes #426 by adding a .#version-check script to report registry versions newer than the versions in the latest package set. This reuses the package set updater candidate traversal instead of being brand-new.

I ran the script against package set 77.13.1 and found 19 pending versions. Not all of them can compile together, but 14 of them do, and that's submitted as purescript/registry#560.

Five versions were intentionally left out:

• barlow-lens@1.0.0 breaks morello@0.4.0, which uses the old Barlow API and declares <0.10.0.
• elmish@0.14.0 breaks elmish-hooks@0.11.0; meanwhile, elmish-html@0.12.0 requires Elmish 0.14, so neither Elmish candidate can move until the dependent packages are compatible.
• hyrule@2.4.0 removes modules still imported by bolson@0.3.9, deku@0.9.24, and ocarina@1.5.4.
• node-child-process@12.0.0 changes the exit API and breaks dotenv@4.0.3 and node-execa@5.0.0.

So this is the point of the script: surface upgrades that automatic daily updates could not accept so maintainers can identify and submit a compatible coordinated batch.

[f-f]

This is cool - two things come to mind:

• we should have a policy of dropping packages that are holding on updates for too long. E.g. picture the scenario where a package that has many dependants is blocked by a package that has not many users - the former should not be held up. Maybe we can have some sort of expiration (e.g. holding a package for 30 days triggers removal or something like that)
• we could wire this up to @pacchettibotti automatically opening issues in the repos that need updating to the newer version, to speed up the process of the package sets catching up to things

[thomashoneyman]

Yeah, I agree. I don't have a specific policy in mind but directionally I'm on board. To what degree should that be encoded into this script's report? We could augment this with more data than it currently gives.

[thomashoneyman]

Also, we could extend this with a planner that makes it more obvious whether the discovered versions will even work together and suggest a batch. Something like:

1. Give every candidate package two choices: its current version or reported candidate.
2. Check every package manifest against the exact proposed package-set versions.
3. Maximize the number of accepted candidates while satisfying all declared ranges.
4. Repeat until stable, since rejecting one candidate can invalidate another; like for example, rejecting Elmish 0.14 also requires rejecting elmish-html@0.12.0.
5. Run one read-only atomic compilation of the selected plan to prove it

For this batch, this would have discovered the 14 packages that work without me having to do a separate manual triage:

• morello excludes Barlow 1.0.
• elmish-hooks excludes Elmish 0.14, which consequently excludes the new elmish-html.
• bolson and deku exclude Hyrule 2.4.
• dotenv and node-execa exclude node-child-process 12.

...this doesn't help with what you're describing, but maybe we can re-think this script such that it's a more useful swiss-army-knife for helping get the package sets updated with the best options when it can't be done automatically due to breaking changes.

[f-f]

To what degree should that be encoded into this script's report?

I to get us a good glance we could have:

• who is holding up who
• and for how long; that is: how many days ago the incompatible version was published
• how many dependants each of the packages involved have

Also I think we could be running this in a weekly cronjob thing in the Registry repo, opening an issue/PR if it finds something

[thomashoneyman]

d283822 has some followups that address your points:

1. The version check now produces JSON and markdown reports, which themselves cover staleness, direct and transitive dependant counts, blocked version ranges, reverse blockers, compiler compatibility, etc.
2. It also includes a planner which uses our bounded ranges; it considers current and compatible newer releases, maximizes upgrade count and then freshness, and supports coordinated upgrades
3. You can optionally compile the planned payload with --verify so that you know the proposed plan will work
4. Adds a weekly workflow which writes to a rolling issue with that week's report (doesn't actually submit anything)

Tried it out with a live run against package set 78.1.0 / compiler 0.15.15 and it produced a workable plan — including settling on hyrule@2.3.9 as an ugrade since 2.4.0 is blocked.

[thomashoneyman]

Latest commit is a prototype, still hacking on it a little. But as I was working on the version check script, I realized we could be doing a lot more automatically — and still safely — to update the package sets. Our current automatic upgrade is basically just "try all new packages in the last 24hrs, and if any fail, go sequentially and only include ones which succeed." Very naive, and if a package doesn't work in its 24h window for whatever reason it is never retried — even if it would work later on (such as a dependency finally upgrading).

So the new prototype implements one shared planner that can be used by both the package set updater and the version check workflow. Any version of a package that's already in the set which is newer than what's in the set is eligible for any new plan, plus recently uploaded packages even if they've never been in the set. We restrict to a single compiler version but otherwise ignore ranges. We still try all packages first, but then we do bounded best-first latest/intermediate/current searches.

The package set updater, if it is capable of finding a nonempty addition/upgrade plan, can just submit it. If it finds removals, downgrades, etc. then we can have that notify trustees for action, but it will never be automatically done.

[greptile-apps]

Greptile Summary

This PR adds a PackageSetVersionChecker script and GitHub Actions workflow that compile-verifies all pending registry upgrades against the latest package set and reports both automatically-applicable updates and manually-reviewable removals. It also refactors the package-set API to be strictly atomic (removing the previous sequential/partial-success path), extracts the compile-guided planner logic into its own PackageSetPlanner module, and updates the spec to reflect the new guarantees.

• New PackageSetVersionChecker script: reads all registry metadata/manifests, re-uses the plannerCandidates traversal from the updater, plans upgrades with planUpgrades + analyzeRemovals, and renders a Markdown report with compile-verified payloads ready for trustee submission.
• PackageSetPlanner extraction: the planner logic (phases 1–5, removal analysis, interaction components) is now a standalone app/ module shared by both the updater and the new checker.
• API now enforces atomic package-set updates: upgradeSequential is removed; the server only accepts and publishes an exact, pre-planned payload in one shot.

Confidence Score: 5/5

The PR is safe to merge. The new checker runs entirely read-only, the planner extraction is well-tested, and the API switch to atomic-only semantics is a deliberate, clearly-reasoned design choice with matching spec updates.

The core logic reuses heavily-tested planner infrastructure, the report rendering has no mutable side-effects, the workflow correctly guards issue creation with hashFiles, and the atomic API change aligns the server behavior with the offline planning model described throughout the PR.

Files Needing Attention: .github/workflows/package-set-version-check.yml — consider whether a periodic schedule trigger should be added alongside workflow_dispatch.

Important Files Changed

Filename	Overview
scripts/src/PackageSetVersionChecker.purs	New script: runs the planner against every registry version newer than the latest package set, then renders a Markdown report with compile-verified payloads. Logic is clean and correctly delegates to shared planner/updater helpers.
.github/workflows/package-set-version-check.yml	New workflow: triggers only on workflow_dispatch (manual). Correctly guards issue creation with hashFiles check, but lacks a schedule trigger for periodic automated reporting.
app/src/App/PackageSetPlanner.purs	New module: extracts the five-phase compile-guided planner and removal analysis from the updater into a shared app/ module. Implementation is well-structured with clear invariants.
app/src/App/Effect/PackageSets.purs	Removes UpgradeSequential constructor, upgradeSequential function, and orderChanges helper — simplifying the effect to atomic-only semantics.
app/src/App/API.purs	Switches packageSetUpdate from upgradeSequential (partial success) to upgradeAtomic (all-or-nothing), aligns commitMessage call to use full changeSet instead of succeeded subset, and fixes log codec to use packageSetOperationCodec.
app/src/App/GitHubIssue.purs	Simplifies signPackageSetIfTrustee to take only the operation (not the inner data), and switches readOperation to use packageSetOperationCodec — keeping encoding consistent with the new atomic API contract.
app-e2e/src/Test/E2E/Scripts.purs	Updates runPackageSetUpdaterScript to wire PackageSets, Storage, and RESOURCE_ENV effects that the refactored updater now requires; exposes workdir and cache in the shared RegistryScriptSetup record.
nix/overlay.nix	Adds package-set-version-checker to the scripts map so it is built and exposed as a Nix flake app via nix run .#package-set-version-checker.
SPEC.md	Fixes a syntax typo in the JSON example and rewrites Section 6.3 to accurately describe the new atomic planner-first approach, constraints, and the trustee manual-intervention path.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[workflow_dispatch] --> B[nix run package-set-version-checker]
    B --> C{Latest package set?}
    C -- No --> D[Log warning, exit 0, no file written]
    C -- Yes --> E[Read all metadata + manifests]
    E --> F[plannerCandidates with empty additionSeeds]
    F --> G[planUpgrades: phases 1-5\nprobe budget 60]
    G --> H[analyzeRemovals\ntotal budget 100]
    H --> I[renderReport: Markdown]
    I --> J[Write version-check.md]
    J --> K[Upload artifact]
    K --> L{hashFiles != empty?}
    L -- No --> M[Skip issue creation]
    L -- Yes --> N[gh issue create]

    subgraph PackageSetPlanner
        G
        H
    end

    subgraph PackageSetVersionChecker
        E
        F
        I
        J
    end

Loading

_{Reviews (6): Last reviewed commit: "Automate compile-guided package set upda..." | Re-trigger Greptile}