How to get entire code inside Python Script

I’m trying to get the code inside a component as output.
For example, in Grasshopper, it’d be using ghenv.Component.Code. What would be the equivalent way of doing it in Dynamo?

Also, are there hidden variables in Dynamo similar to grasshopper’s ghenv, ghdoc, etc., Dynamo API Docujmentation?

I’ve seen this (Dynamo API documentation), but how do I use this? Neither direct import nor clr.AddReference would work.

What I’m trying to do is something similar to the Ladybug’s Export Ladybug component ( so i could place my python scripts under VCS.

and for python is this a starting point

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 do also use VSC for this…

1 Like

Hi erfajo,
Thanks for the reply.

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.

Does it mean that it will be possible at some point?

I’m not sure, likely not in the way you want. I know we’ve talked about this a bunch before :slight_smile:

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.


I kinda want to do this just to see what ‘bad’ means…

Thanks for all the input guys!
I’ll try out @Mostapha 's repo. I might also look into parsing XMLs.

On another note, does anyone know how to use these?

Thanks again.

the API you linked is what I alluded to in option 3 (write a meta dynamo library) which calls those APIs - to see how they are used look at how dynamo starts up.

or here for the command line runner which is a simpler use case:


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.


Btw, what did you mean by XML, JSON and 2.0?
By XML, were you referring to viewing the dyf files like this: ?

<Workspace Version="" X="109.287814" Y="209.2361" zoom="0.752660" ....">
  <NamespaceResolutionMap /> 

And by json, you mean the json file inside packages: pkg.json?
What were you referring to as 2.0 though?

Thanks again.

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.

Check the github for info.

1 Like

ironPython emits IL just like c# as far as I know - you can import these dlls into ironpython or c#.

I see, I guess that’d be more convenient.