Did we just accidentally implement a LuCI interface for NixOS?
love seeing this, props on your progress!
there’s a need to configure these modules from diverse frontends, such as:
i’m missing TUIs from that list 
(disclaimer: i’m not aware of any existing tui-jsonschema-form)
That would be amazing, but I don’t understand how. I’m not too familiar with LuCI. Could you elaborate?
Sorry for the late reply, I was preparing for an exam the past days. LuCI is a settings panel developed as a basic component of OpenWRT, which basically consists of a list of settings (Click to select, drop down, input box, etc. things we can normally see in the settings interface), and some information such as IP address and load statistics.
For settings part, see https://openwrt.org/docs/guide-user/base-system/uci
This is dope!
I started trying to implement something similar, but in the opposite direction (JSON Schema → Nix option declarations), but I’ve been stuck trying to figure out how I want to handle meta-schemas, since accepting arbitrary JSON Schema input means I’ll have to collect the entire closure of all the meta-schemas and vocabularies reachable by any schema that might be fed as input. That and handing meta-schema specific keywords like $dynamicAnchor and $dynamicRef.
This blog post and implementation has me thinking I may be taking the wrong approach and maybe I should try to get an MVP working that ignores all the meta-schema shenanigans to focus on just the structures common to a broad set of non-meta schema documents.
If anyone has any insights on JSON Schema or useful resources that would help with parsing all the references, I’d greatly appreciate it! Kinda kicking myself now for not taking a compilers course in school.
oo, what use-case did you have in mind for this?
focusing on the commonly used structures def seems fair! i know json schema can get tricky with stuff like anyOf / allOf…
for resolving of json schema references from python i’d been using jsonschema-path, tho other languages should have their own tools.