I’m writing tool which manages/generates .kicad_jobset files. I didn’t find any documentation for this format. Would it be possible to document this? I would totally understand if the development team would not want to commit to stability of this file format but having information on this would be very helpful for me (and I imagine the broader KiCAD software / plugin ecosystem).
Unforunately it would be a ton of work to document, there are ~192 setting key/value pairs currently, some with non-obvious internal logic involved. Not to mention a ton of work to maintain the list across versions. Key/value pairs may also be dropped on a whim between versions. The intention simply wasn’t there for external tools to get involved here.
there are ~192 setting key/value pairs currently
I assume most of these correspond more or less 1:1 to some settings in a GUI Dialog, which might have already some docstrings or similar associated? (Wouldn’t there be enough information available to auto-generate some documentation?)
I would be happy with a json schema or something similar, which would allow me to check my implementation
Key/value pairs may also be dropped on a whim between versions.
as I said I don’t expect a long-term commitment to this format
Yes but no. Most are associated to some dialog setting, but there’s no guarantee it’s a simple obvious relationship. Some settings are dependent on others, etc.
And there’s nothing in code that would tie it to docstrings like that. Most of kicad is documented completely independently of the code because the end user is not a programmer, so we aren’t trying to autogen documentation from code.
The job set system right now is the most organized store of all these export dialogs options. My future goal was to actually start redirecting those one-off dialog exports into the jobset system internals
Would it be possible to offer a way to try to parse a json and see if it is a valid jobset?
We might be able to add some sort of lint function. The problem is it currently does not care about “unrecognized” setting key/value pairs. So if you typo something, it’s not considered an error. This is by design.
These Jobsets are quite new, and as a wild guess, it may be better to let it evolve for a year or two before formalizing the format too much. This gives the developers some extra wiggle room to change things when that fits better with new ideas.
So if you typo something, it’s not considered an error.
The linter command would of course implement strict parsing.
This gives the developers some extra wiggle room to change things
That’s precisely why i believe some strict checker directly from within KiCAD would be helpful for the people who don’t use the integrated GUI to edit their jobset files. (this includes a lot of people, who might just be working around a bug )