We are currently in the process of upgrading Revit. We have customized the pyrevit toolbar to run a handful of our dynamo scripts. These graphs are being duplicated and upgraded to run with the new version of Revit.
Since we have multiple versions of these scripts, we want to ensure that pyRevit will run the correct one. What is the best way to do this? I am finding allusions to two options (I think).
- Setting up the YAML file to run certain scripts based off of Revit Version
2)Attaching pyRevit to installed versions of revit. This seems easy in theory, but I’m confused what this looks like in principle. Are there youtube explainers on this subject?
Let me know if one of these options is better than the other. As this is my first time doing this, I’m not sure which path to take—or if I’m completely off base.
The preferred method is to specify which version of Revit the tool is made for in Yaml file.
We can also modify the bundles to look for Revit version in the name of bundle main file (python, csharp, dynamo, etc.) and run that for specific revit versions.
This would be similar to how
.content bundles find Revit-specific families inside the bundle.
Thanks. So, to clarify.
As I duplicate and update our dynamo scripts to work with revit 2023, I will create a new folder in the pyrevit directory for the 2023 scripts? In the screenshot below, all 2022 scripts have a _22 suffix. All 2023 scripts have a _23 suffix. I then use the bundle.yaml file in each folder to dictate which revit version this particular file applies to?
I’ve started doing this and it certainly works, although it does seem a little tedious.
No not the bundle name. The actual script name inside the bundle. The point is to keep the bundle the same, and provide multiple scripts inside the same bundle:
pyRevit would run
applyFireProofingDognut_2022.dyn only on Revit 2022
Can you please point me in the direction of documentation on how to set up the bundl.yaml to only open up the _2022.dyn and _2023.dyn files in the respective versions using the formatting you show above?
You say earlier it would be similar to the .content methods, but I can’t make the mental connection between the two types of bundles.
@aaronnordstrom This is not implemented. I’m only asking your opinion to see if this would be a good solution.
I think your suggestion would make it a little easier as there would be less folders.
I think what would be ideal is if that versioning could take place further up the folder structure. In the image below, each of the .pulldown and .stack folders have a 10-12 scripts and more are being made. It would make organizing the library easier if we could make a custom_2022.pulldown and a custom_2023 pulldown, sorting out the versioning one time in this YAML file.
That said, I’m very new at all of this so I may not be the best person to say what makes the most sense.
I think you are talking about editing the bundle.yaml file while Ehsan talks about implementing a solution where you would just specify the version by the dyn script name itself (which seems much simpler to manage)
It would require to have the min max version implemented as well in the name *_min22.dyn like the bundle.yaml does already
Yes—in the file name would be great.