It is certainly doable to place your code as py files outside the nodes… I do the same in my package (DanEDU Dynamo). the problem is to give the path to your package. For that purpose have I made a binary file there is being activated when dynamo is started. Then I can find its placement and by that give the path to my OOP environment.
I’m already familiar with the RevitAPI so I don’t think there’s anything in it that might help me extract Dynamo Python Code.
As for using python files and the Python Script From String node or sys.path.append or placing modules inside C:\Users\<>\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages , I already have those as some of my options (I think it was from one of your posts that I got the idea) In case Dynamo doesn’t have any library that allows me to do something similar to ghenv.Component.Code.
I still prefer the ladybug-tools approach of having the src and dyf files separated and under version control but I’ll settle with having the files outside if it isn’t possible yet with Dynamo.
You cannot extract the code as such. If the built-in python node is used, you can edit that and get the code. You cant get the code if it is a Zero-touch node. However, many share their code at GitHub.
I started out doing like “Ladybug” (@Mostapha) but experienced difficulties with that method. I got a bunch of error-feedbacks from mid-November to end-December. I don’t know what went wrong with that method, but I ended coding a binary file instead. That is the method e.g. @Konrad_K_Sobon use in BumbleBee. It seems to be more failsafe, not that I can tell why it wasn’t that with the other method. I cant understand why the former should go wrong.
Where Ladybug has most of the code outside as py files, has BumbleBee it inside the dyf files supported by binary files. I have all my code except the “reader” node as py files in a lib folder (in the extra folder) I use the name ‘lib’, since that is a Python phrase, ‘scr’ is a Java and C phrase.
Having all my code in native py files gives me the advantages to use VSC and sharing the code with others at GitHub that doesn’t know dynamo as such. The code is readable as well-known files not as ”messy” text in a dyf file-format not known by anyone outside the dynamo world.
I have also tried the best to follow the PEP8 standard, but it is difficult when there are some requirements from the Dynamo environment that works against that. When you initiate IN and OUT variables then it will fail a PEP8 test, likewise goes for loading external modules. Some have to be loaded in a certain way demanded by Dynamo (and .net).
You can parse the Dynamo file which is an XML file before Dynamo 2.0 and a JSON file for Dynamo 2.0 and after that. The python code is included inside the file. If you know the path to the Dynamo file then all you need is a parser.
Also you might be interested in dyfpy library which I wrote to convert Grasshopper GHPython components to Dynamo custom nodes. You can use them to create a Dynamo custom node from a JSON file which includes inputs, outputs and the code.
what should really be done here is to use the DynamoCore apis to construct an entirely new dynamoModel, use it to open workspaces, and then query the nodes for things like code. A python or zero touch node today cannot get access to the running instance of dynamo.
I’m not sure, likely not in the way you want. I know we’ve talked about this a bunch before
I would advise these ways forward.
If you want to interact with the currently running instance of Dynamo - write an extension. You can access the workspace, nodes, etc. We’ll be looking soon into how devs can distribute packages without building their own installers.
write a hacky node model node that goes and gets the dynamoViewModel from the NodeViewModel and then go crazy. This is hard to find because it’s bad and likely we should remove this reference.
I would love to make a metaDynamo zerotouch library which would call the dynamoCore.dlls from within dynamo… this would let you start a new DynamoModel, open graphs, save graphs, inspect graphs, modify them, etc. Just isolated from the dynamo you’re currently executing in, think of this like a python engine node but for graphs and design script.
Not sure what you meant by meta library but does that mean they’re only accessible using ZeroTouch nodes, i.e. they’re not available inside python nodes using methods like clr.AddReference?
Although I do have some minor experience using C#, I haven’t tried ZeroTouch yet so I’m clueless.
I think @Mostapha is referring to the fact that Dynamo 2.0 and up uses json under the hood instead of xml, which is what previous versions used. I believe this was worth bringing up in more detail here as code you write today that disassembles xml data from dynamo core nodes may need to be rewritten for 2.0 and later in the future.