Currently we export node properties using an auto-generated node_settings.py file, which lists the properties, types, and versions for the RNA properties of a node. The script that generates this file parses through the Blender docs to gather all the required properties, which presents a few issues
- It's very slow to download and parse through HTML, compared to just reading directly from the RNA props.
- It requires the docs to be up-to-date when developing for a new version
- Changes in formatting break the script. The 5.2 LTS had a new layout that required re-writing parts of the script
Additionally, NodeToPython currently has a lot of special handling for all the different types that go into exporting a node tree, with many different functions for each type. This is largely done manually, which slows down development and has been prone to errors like missing properties.
Reading straight from the RNA properties would allow for a unified representation of the export, and new types could be introduced without much, if any effort, hopefully limiting to just writing new tests for new versions.
We also should be able to cut down on the verbosity of the exported code. NodeToPython is fairly conservative right now, exporting all properties even if it hasn't been changed from the default. An option could be toggled to explicitly export all properties, or not bother exporting the default ones.
We'll probably want to manually maintain a list of ignored properties for each class, so that objects can look at all their ancestor classes and choose not to export certain properties (e.g. bpy.types.Node.bl_height_max).
Currently we export node properties using an auto-generated
node_settings.pyfile, which lists the properties, types, and versions for the RNA properties of a node. The script that generates this file parses through the Blender docs to gather all the required properties, which presents a few issuesAdditionally, NodeToPython currently has a lot of special handling for all the different types that go into exporting a node tree, with many different functions for each type. This is largely done manually, which slows down development and has been prone to errors like missing properties.
Reading straight from the RNA properties would allow for a unified representation of the export, and new types could be introduced without much, if any effort, hopefully limiting to just writing new tests for new versions.
We also should be able to cut down on the verbosity of the exported code. NodeToPython is fairly conservative right now, exporting all properties even if it hasn't been changed from the default. An option could be toggled to explicitly export all properties, or not bother exporting the default ones.
We'll probably want to manually maintain a list of ignored properties for each class, so that objects can look at all their ancestor classes and choose not to export certain properties (e.g.
bpy.types.Node.bl_height_max).