Repository navigation
schema: add diff engine + real schema corpus (foundation, no CLI yet) - #20
Merged
Merged
Conversation
Phase 0+1 of the schema-diff idea: comparing Hyprland's API between two
versions to eventually warn a config about upcoming breakage, not just
validate against whichever one version it's pointed at today. This PR
is the foundation only - a diff engine and the data it needs - no CLI
surface, deliberately: wanted the core comparison logic validated
against real version transitions before deciding how to expose it.
- schemas/v0.55.0.json .. v0.56.2.json: one real schema per tagged
Hyprland release (all 8 that exist), not synthetic fixtures.
Cross-checked against schema.json already in this repo - identical.
- scripts/generate_schema_history.py: regenerates/extends the corpus.
Confirmed generateLuaStubs.py is pure static analysis over C++
source text (no build needed), and that it must be run as *each
tag's own* copy against *that tag's own* source, since the
generator's own parsing logic has changed across versions. Verified
end-to-end against the live Hyprland repo - regenerating a removed
schema reproduced it byte-for-byte.
- hyprvalidate/schema/diff.py: diff_schemas() - classes/fields/
aliases/config-keys added, removed, type-changed, plus a
conservative "possible rename" heuristic (fires only on a clean 1:1
same-type match, never guesses past that).
Tested against two real, dated Hyprland regressions found while
researching this: hl.permission{}'s allow -> mode (Hyprland#14400,
broke one day after Lua config shipped) is a clean 1:1 match the
heuristic catches; HL.Window's over_fullscreen -> allowed_over_fullscreen
(Hyprland#15367) is genuinely ambiguous by type alone (two new
booleans were added, not one) and is deliberately left unguessed.
Every diff is phrased as "the schema changed," never "this will
break" - the generated stub has itself lagged real Hyprland behavior
more than once (the allow/mode field was wrong from the version it
first shipped in), so a schema diff is evidence of a possible behavior
change, not proof of one.
This was referenced Aug 28, 2026
Merged
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.
Summary
Phase 0+1 of the schema-diff idea (comparing Hyprland's API between two versions to eventually warn a config about upcoming breakage, not just validate against whichever one version it's pointed at today). Deliberately foundation only — no CLI surface — wanted the core comparison logic validated against real version transitions before deciding how to expose it.
schemas/v0.55.0.json..v0.56.2.json— one real schema per tagged Hyprland release (all 8 that exist), not synthetic fixtures. Cross-checked againstschema.jsonalready in this repo — identical.scripts/generate_schema_history.py— regenerates/extends the corpus. ConfirmedgenerateLuaStubs.pyis pure static analysis over C++ source text (no build needed), and that it must be run as each tag's own copy against that tag's own source, since the generator's own parsing logic has changed across versions. Verified end-to-end against the live Hyprland repo — regenerating a removed schema reproduced it byte-for-byte.hyprvalidate/schema/diff.py—diff_schemas(): classes/fields/aliases/config-keys added, removed, type-changed, plus a conservative "possible rename" heuristic (fires only on a clean 1:1 same-type match, never guesses past that).Grounded in two real, dated Hyprland regressions
hl.permission{}'sallow→mode(hyprwm/Hyprland#14400, broke one day after Lua config first shipped) — a clean 1:1 match the heuristic catches confidently.HL.Window'sover_fullscreen→allowed_over_fullscreen(hyprwm/Hyprland#15367) — genuinely ambiguous by type alone (two new booleans were added, not one) and is deliberately left as a plain removal rather than guessed at. Asserting this negative is the point: a wrong confident guess is worse than an honest gap.Every diff is phrased as "the schema changed," never "this will break" — the generated stub has itself lagged real Hyprland behavior more than once (the
allow/modefield was wrong from the version it first shipped in), so a schema diff is evidence of a possible behavior change, not proof of one.Test plan
pytest tests/— 203 passed (3 pre-existing/environmental entry-point failures unrelated, deselected)scripts/generate_schema_history.pyrun end-to-end against the live Hyprland repo (temporarily removed one schema, regenerated it, byte-identical to the original and to the repo's ownschema.json)v0.6.0beta) and find exactly the 8 real Lua-era releases