I have developed scripts to lighten the workload for the Revit designers in my company. My scripts rely on some packages and that’s just fine for me. But the end users are not familiar with Dynamo and having them configure their systems to be compatible with my scripts is asking too much. I am looking for way to convert these scripts into a format that Dynamo Player can run in its default configuration.
I’ve got all the scripts and packages saved in a central location (accessible by all).
Then IT has a macro that’ll push the packages to each users C drive.
The only thing users have to do is point their Dynamo Player to the scripts (one time only thing). I’ve written a step-by-step guide with pictures for how to do this. The step-by-step guide is given to all our new starters.
Works fairly well most of the time 
2 Likes
I’d recommend searching the forum, there are a lot of discussions about this subject.
@Alien’s suggestion is a good one, but maybe doesn’t address the core question about a “way to convert these scripts into a format that Dynamo Player can run in its default configuration”.
To me, the short answer is: Replace all Custom Nodes with Python.
I recall a long back and forth (I thought recently) about this where @jacob.small came out very against this idea, as it puts the onus on you as the developer to update whenever the Revit API or Dynamo changes, whereas if you use packages the maintainer of the package (in theory) takes some of that burden off you. I can’t seem to find that discussion, but he makes his point here:
@steven.jensen has a super detailed post about his method here:
Also this:
and this:
and this:
and this:
3 Likes
I thought about replying with that answer, however, it’s overkill in 99% of cases I’d say.
I mean. it’s not that hard to have a folder with the used packages.
I don’t disagree- but you can see I edited my post to complicate the “simple” answer.
Good read here:
1 Like
Yeah, this just moving the pain from ‘configuring the end user’s Dynamo environment for their version’ to ‘configuring the end users Dynamo graphs to their version’.
Moving to your own Python in a custom node is great though. Here’s why.
Let’s say that getting a parameter value was not as simple as the “Element.GetParameterValue” node in Dynamo. To achieve our outcome we have to either write a Python script or write a DLL in C# to get to the Revit API and access the info we are after. For now let’s focus on Python, and assume we want to support Dynamo for Revit 2021 to 2024 (selecting these four builds to match the restriction of RevitAPI docs links).
As the Revit API changed the way we access each of the following, we have to update one (or both) of those options each year:
- 2021
- The big Revit list: API Changes 2021.1
- This doesn’t look to bad. If we were migrating code it isn’t too tough.
- We’ll need to support Dynamo 2.5 as a baseline here.
- Since this is our base I won’t pontificate ont he
- 2022
- The big Revit list: API Changes 2022
- Parameters are different than they were in 2021, so if you were migrating from 2021 to 2022 you have to account for that, and as we want to return the readible values… yeah this is a lot.
- We’ll need to cover all the changes up to Dynamo 2.10 from our previous base of Dynamo 2.5, which is not too much - only 275 lines of release notes.
- This is a big lift due to the parameters changes - they look small in hindsight but at the time basically all Python suffered.
- 2023
- The big Revit list: API Changes 2023
- Nothing to worry about in general so this looks like an easy year…
- The base Dynamo build only jumps to 2.13 so only 3 versions of release notes to deal with but 2.13 was so big it took 3 blogs to summarize and by the way IronPython is no longer shipped so you’re dealing with packages anyway or ALL your python need to be reviewed.
- This is a big lift due to the Python update, and also the Dynamo update even though Revit wasn’t that bad.
- 2024
- The big Revit list: API Changes 2024
- Element IDs jumped to 64 bit and we have a BUNCH of parameter api changes too so this is going to be ugly.
- Dynamo changes up to 2.17 so four versions of release notes to deal with.
- This is a tough release due to both the Dynamo changes and the Revit API changes - no easy way around this one.
- 2025
- Including this one for ‘forward looking’, even though I don’t have a “big list” for Revit.
- We do know that both Revit and Dynamo updated to .net 8, so anything we had in prior builds is apt to break and needs testing or a re-write.
- Python is included in this, so you can’t just push IronPython 2 and be done with it - to scale you HAVE to manage 2025 environments differently than 2024
You likely have other use cases, but similar changes happen for pretty much every version and use, but it’s worth considering all of that in your own context to identify stumbling blocks. Any change to an API you call will likely require different Python between builds at some point.
Ok, now that I’ve done some homework and pointed out ‘what sort of stuff’ changes year to year, let’s talk about how you can manage the changes.
- Python on it’s own works, but you’ll have to either add the checks for versions and environments to call the right version of the Revit API in your graph each time you call the code, or use different graphs each year based on the user’s environment which is shifting from ‘user the right package’ to ‘use the right graph’ and the later is more user facing. The ‘if’ checks for versions also slow things down, often a LOT and your code bases get huge for no reasons this way.
- Python in a custom node works better, as the same graph can call different environments and you can ‘mask’ the differences for the users. This requires managing packages which was the method that Python was intended to avoid, so not really circumventing that issue by moving to Python here. It also means that when a partial update is released that breaks your code you can update the Python once and deploy to the local systems and it’s good going forward. Each year you just check your packages against each dyn.
So for this reason I recommend using packages as you get benefits without much (if any) additional work.
1 Like
Thanks @jacob.small and everybody else who contributed. I am pretty far from having the expertise to implement a Python solution, so I will figure some way to get the correct packages to everyone who wants to use my scripts.
1 Like
The first step is to collect the packages you want in each Revit release into a directory on the network. Put those in a directory and ask your IT team how the recommend distributing them to end users’s %appdata% folder for their Dynamo installations.
Note that you can’t effectively run these off cloud locations or a network due to common security protocols (you do not want to execute random code from the internet as a rule), and even common to all user locations (i.e. %programdata%) can be problematic due to packages frequently not having all DLLs signed. This is why I recommend the default appdata folder.
If IT won’t help, first recommend your management get better IT. Then after you explain that you’re doing someone else’s job? look into robocopy, GPL, building an exe or installer, or utilizing Python or another scripting language to copy files from the network to end users.
A few years ago (like 20) when i was the IT side of things as an administrator on the server side, in a company, we implemented startup scripts (RoboCopy) for every individual user, and some grouped as being administrate, some architects, some Revit users and so on. I remember .bat files
Since then much has changed i guess.
Jacob,
Thanks for your detailed and well-reasoned (as usual) post. This will be the answer I point people to in the future!
That said: @Thatcher , I highly recommend you read @steven.jensen’s post I linked to above. He goes into great detail about the steps required, I think you’ll find it helpful.
1 Like
Not really - the process is still extremely common. Known as “Group Policy” and it controls ‘who can see what’ by both groups and individuals (i.e. give this user access to that file), as well as allows setting up configurations and files locally for the user.
You can learn more here: Using Startup, Shutdown, Logon, and Logoff Scripts in Group Policy | Microsoft Learn
Note that you as an end user should not have have sufficient privileges to implement one of these in an office, as ti is a network admin task.
1 Like
The post I wrote about “…without IT” was a method we used when I worked at smaller organizations. Now that I am at a large organization we have IT and login scripts with Group Policy, but we are still distributing the packages and graphs using similar methods.
1 Like
In Group policies you can nest groups in groups like a tree if i remember that right
1 Like