Hey all, Kind of a pyrevit related question but also Dynamo…
I want to run a .dyn file from the pyrevit ribbon, but i can’t use the normal method of placing the .dyn file in the pyrevit folder, since our company uses 3 revit versions.
So i need to use a python script that executes when the ribbon button is pressed, which then checks which revit version is running, and then opens the .dyn file corresponding to that revit release.
No, you need to build and deploy for each Revit environment… Writing 3x code versions and asking it to check is 100x worse from a management and performance standpoint.
For instance with exporting PDF’s, pre 2023 you need to use ‘Print PDF’ and from 2023 and onward you can use ‘Export PDF’. I need to manage multiple graphs for this as well… Probably the only example i can think of where i actually need multiple graphs instead of just one that runs in all versions…
I do wonder, do you keep the package versions across all revit versions you use the same?
Units API and graph scale changed in 2023 so you have two there.
Element IDs changed in 2024 so you have one there.
And 2025 uses .NET 8 which means many interfaces from IP2 won’t work so onto CP3 you’re finally forced.
So Revit API wise there are no changes unless for graphs with no units, measurements, elements, or interfaces…
Instead of ‘copy - paste - hope’ I recommend you build, test, and then deploy each graph for each Revit environment so that environment only sees it’s graphs. It just works that way - less than that you’re stuck hoping.
Well yeah i build the graphs for the specific revit versions, but when you want to make the move to run dynamo graphs from the pyrevit ribbon, you run into the issue that you cant select a graph based on which revit ‘year’ you’re in. You can paste one graph in the button folder and that’s it, which does not work as pyrevit is the same across all the revit versions.
So you are either stuck utilizing a dropdown list like this to make the user select the graph that is for the current revit version:
From experience, if you reach this point it is time to look into pyrevit in python where you get flow control and can check revit versions in a script (or on to C#). The inability for dynamo to easily work cross version was literally what got me to python and pyrevit personally.
You could technically check revit build in dynamo also and modify script behavior in python nodes as well, but at that point its better to just script it as pyrevit intends.
Yeah that’s why I was asking :)I think there’s a small misunderstanding on what I am trying to do
I want to get me and my team started using pyrevit, and I thought a logical first step would be to launch some of my most used graphs around my office with a pyrevit button. This gives me the opportunity to get to know pyrevit and figure out how to build pyrevit tools while getting coworkers on board by them using new buttons that present the same functionality as the graph, but now without having to launch dynamo player and selecting a folder first…
But I immediately run into the issue where I don’t see any possibility on how to run a graph via a pyrevit button, created for that specific Revit environment. I’ve seen you’re video on how to execute a dyn file through pyrevit but this only works when you use one Revit version. I was hoping I could use a python script as an intermediate before executing a dyn file like so:
Press pyrevit button > execute a python script > script checks which Revit version is running > script executed dyn file from folder: …/2024/script dyn if it’s in Revit 2024, …/2023/script dyn if it’s in 2023 etc.
The above is the reason why I want to see if I can move to pyrevit for atleast some part. It’s a pain getting my coworkers to add the correct folders in dynamo player for each Revit environment
I began looking into this as well and I don’t believe you can herald a dynamo tool or script via a python script - at least in what I found (or in this case, didn’t).
This thread covers the options which seem limited to running a python script but not a dyn via a script using pyrevits ScriptExecutor class:
The only solution they give needs dynamo to be open which probably isnt a solution for the typical user.
You might be able to post the command to open dynamo and use a while loop until its process is found, then use that workaround, but im skeptical it would be safe/viable to run in this unintended way.
Hey @GavinNicholls - are you suggesting that if there was better flow control (via nodes) in Dynamo where you could execute a different subgraph based on host version that would open up better cross version use cases for Dynamo graphs - or that’s just the first missing feature that would be needed?
No in this case suggesting you can version check and call on different functions in a python node to handle deprecations, changes or builds before availability of API capabilities.
It is interesting to think of how Dynamo graphs could function across versions. We would, I guess have to be able to choose alternative node (groups? sort of how the family editor works?) to fire in different versions.
I guess Dynamo would have to give warnings of API depreciations and prompt whether an alternative ‘node group’ is to be selected?
It would rely on the graph being edited in the most current Revit version, and the user would need previous versions installed so Dynamo could allow the user to choose previous nodes to build the alternatives.
Not straight forward, I think this would a good PyRevit / Dynamo Player request? Add a subfolder for each year version to use…
Honestly it 1000000% feels like the PyRevit installation just needs a ‘load from’ for each Revit environment instead of trying to use one folder for all environments… Shouldn’t take long to add but the project has 10,000,000 more important things to worry about at the moment.
Dynamo Player already directs to a distinct version for each release.
Player’s going to path to whatever directory you point at, so if a graph in that directory is built for X and you’re in Y it might fail, but if you build for each version it should be fine.
At that point I think users would just be better off heading to C#. Pyrevit is primarily intended to have tools in Python, where version detection and control flow are easily achieved - I have plenty of tools where I work which handle differing API needs by version in single scripts. Dynamo script running via pyrevit always felt to me a little bonus vs its intended use, knowing my tools all just load the same way regardless of build is a selling point for me vs an issue.
I’m of the mindset that they are nowhere near easily achieved - you actually make it harder on yourself. The only reason the “flow control” like this works is:
Added execution time due to extra overhead,
Introduction security vulnerabilities (one company who offers paid support for IP2 lists ~40 patches they address so this isn’t trivial)
Multiple more layers of ‘well you gotta know this’ instead of just running the Dynamo graph with packages and such.
Added time to write EVERYTHING in Python instead of using the Dynamo Ecosystem.
In any case, at some point you need to write the code for ‘one build’. In my perspective when you get it working for version X why not publish it then, then move onto version Y to test/fix and publish for the next environment? It’s no less work for you as a developer, users get faster running and more reliable code, and it all happens faster as you don’t have to test environment 1 when you make the changes for environment 2-4.
One way I can see to circumvent the issue is with packages. Could be a Dynamo package as the ‘right code for this version’ and load just that version into Dynamo. Or it can be a Python package as you can direct it to load the module from the X, Y, Z, or A folder based on your Revit build. You could also ‘mix and match’.
All of that said, I am of the opinion that Dynamo Player to execute the graphs is better here if you’re running Dynamo graphs. Yeah you lose a “ribbon feel”, but you still get icons, help documentation, inputs an configuration, results preview, and more.
If you really want the Ribbon, then as you said moving to a Revit Add-In is going to be easier in the short and long run. Plus you’d be able to use 2025 already (based on historic release schedules 2026 is about 5 months out now by the way), would be as secure as could be, and would run faster.
This flow control has not been difficult for me to achieve using pyrevit, and haven’t witnessed any major performance hits. I generally solve this using separate classes or functions, then when a version difference hits I just call on the right one, typically storing them in a library to keep code clean.
From what I understand the C# approach isn’t too different. You can share a lot of code across builds and then handle build specific parts across different solutions where needed. Might be mistaken as I’m early in, but I’ve seen a few guides where they avoid copying entire solutions just to handle different builds.
If we’re talking Dynamo specific then I agree that you’re going to better off managing different scripts to keep the learning curve down, although I’m not sure how feasible hot loading packages per version is currently whilst keeping that curve low. As far as I know only Rhythm and Orchestra have got that logic going.
It’s just a thought… Users want the cleanest experience, if the user has to choose a graph depending on their Revit version, it’s additional clicking which I’d rather take out of their hands.
I was thinking that if, say the graph had metadata I could complete on save to say the version, could player only display those? Then the user only sees relevant graphs?
My thought it that the application should only load the code relevant to that version, not all versions, and nor should the code be written to cover all versions.
There is a reason Word has different installers for Windows and Mac…