NXT dev here, great questions!
- At the moment, no we do not have a way to “print” a graph to a
.py file. We’ve talked about it and have some ideas, but nothing solid yet.
- Yes! We’ve taken special care to support
lambda in the node code block. We have a unittest just for that, if you can break it please let us know.
- We have several ways to control the execution order. In general, yes, without special direction NXT will execute hierarchies depth first. However, our API allows you to execute arbitrary lists of node paths. Also, multiple start nodes can be saved into a graph and the API can be told to execute from those points.
Build system persistence, as you put it, is something we’re always pushing on. We have plans for a
pause > edit > resume workflow, as of now we just have a
pause > inspect > resume. At any point its possible to see a “cached” view of the data, in that view NXT shows exactly what code ran, as well as what attributes are available on the
self objects. We do have a widget called “Workflow Tools”, not yet documented. It basically allows you to create a little window with buttons for executing nodes on demand, very powerful for riggers. You can see it used in the openrig graphs.
As far as rename propagation goes, we do have a basic find and replace system that we hope to expand as we have the time and need.
Our visual editor is fully separated from from our core API, so with only the core installed you can execute graphs. Its designed so that the actual logic to load and execute graphs only relies on built-in Python. Allowing farm nodes to run NXT with as little friction as possible.
We see NXT as an execution orchestrator, meaning your heavy lifting logic is probably best left in external libraries. Going back to your first question, we’ve seen the value in having a way to get your orchestrating code out into a giant build script, but we haven’t landed on the right way to do that.
We really appreciate feedback positive and negative. We want to make NXT the best tool it can be.