Conversation
|
I haven't read this in detail yet, but is the main thing that it does over the existing yaml type checking just looking for fields that don't exist but generally should exist? If so, I think the code could probably be a lot simpler if it was integrated into the current build pipeline more. Right now there's a lot of duplicated logic here for eg resolving the inherits. There's already code in the main build pipeline that resolves the inherits and may handle some edge cases and other stuff you haven't thought of. Ideally what you want is to use the existing build pipeline to generate the "completed" spec objects with all properties resolved, then just check the list of properties there contains all the expected ones. I'd expect it to be a lot fewer lines of code than this. Of course, if this tool is useful to you as-is, go ahead and keep using it, but if you want to merge it into the main specdb codebase I'd want it to be integrated more cleanly. |
|
Yeah, this was mostly a way to assign a spec to a certain type, similar to how i've had to do it here in rust https://github.com/Sam-Mear/specdb-rs/tree/master/src/spectype Currently row-data only has all the specs, with no metadata on which type of spec it applies to. Was mostly for that, then AI'd to do more - so was probably sloppy anyway. I'll mark as a draft for now. |
2 participants
No description provided.