First, I apologize for the mega post, but this is something that is occupying quite a bit of my time and energy as of late.
Rhythm is becoming quite difficult to update to offer support for several versions of Revit. This post is meant to gather information from the community in terms of usability.
As you may have seen recently, custom packages have become increasingly more difficult to maintain. This goes for both C# (ZeroTouch) and Python packages (Python is definitely not off the hook as the IronPython deprecation, screwed a lot up too).
A few posts specific to Rhythm can be viewed here:
The issues that are demonstrated in those posts vary between Dynamo changes and Revit API changes. Both of these are very hard to tackle when working across several versions of Revit/Dynamo.
At this time, Rhythm tries to support Revit 2021 through Revit 2024, but there are many hurdles when working on that many versions (outlined in the next sections below).
As a package author, when you build a Dynamo package you typically target the latest API, (Revit 2024/Dynamo 2.18). This works great when the package is used in that version as your user is “in the environment that you built for”. This works less than great when the user is in an older version that you simply didn’t test for. To contrast this, as Revit plugin authors, we multi-target our plugins for each version of Revit directly.
“Why is this node saying it wants an ElementId that is 64-bit?!”
For reference, 64-bit element id is a big API change in Revit 2024, from 32-bit Element Ids, that are just marked as “to be removed in the next version”. The Dynamo for Revit team decided that 64-bit is all they want to support, so there is no chance of making it work across multiple versions if you are using certain methods. One of these methods that break in older versions if you target Revit 2024 Dynamo is the infamous,
ToDsType(true) for casting elements back to their Dynamo variants.
The reason I am creating this post is that I have gone back and forth dozens of times on how to handle this.
Note: Please don’t reply, “My package works great, and it is easy to do” if you don’t have open-source examples proving it. I don’t have the time or patience to deal with “1-uppers” and people who act like their stuff is perfect.
Also, this is a Dynamo question. So please don’t reply “use pyRevit” or “use RhinoInside” because that is not the same thing, and a reply like that is frankly, extremely unhelpful.
While I am sure that some strategies can work well unless there is an open-source repo that I can follow along, I am going to entertain the other options I have on my mind.
Here are the options I am considering, with their pros and cons.
The package manager is the simplest way to install a package. Which is the primary reason Rhythm has always been available this way. However, there is no control at all over which version a user will download, because 99.9% of users will just click the big install button. Historically, we can see that this has been an issue for archi-lab as well.
Additionally, the package manager lacking certain support across Revit versions is the main reason Lunchbox has left as well.
This is also the reason that Orchid is available on GitHub as its own installer.
|Version Controlled Installer||Not easy to install for a lot of users|
|Managed like a Revit plugin||Security Concerns with Exe|
|Package manager is the primary installation for most users|
This one I like from a usability (package installation) standpoint, but I dislike it from a package author standpoint.
The idea here would be to have a version of Rhythm for each Revit version. So you would have the following:
- Rhythm for Revit 2020
- Rhythm for Revit 2021
- Rhythm for Revit 2022
- Rhythm for Revit 2023
and the default package “Rhythm” would always be for the latest version, (at this time that is Revit 2024).
The downside here is I am not 100% certain that Dynamo would resolve the nodes on its own. Frankly, I don’t want to trust Dynamo’s resolution of almost anything anymore.
|Easy to understand from installation POV||Node resolving is questionable|
|Default “Rhythm” package might still get installed on old versions|
|Several packages for me to maintain|
This option is less than ideal because this leaves users on older versions of Revit confused as to what to install. This is similar to the archi-lab deployment method, where users have to manually go to the versions and install the one that corresponds to their version of Revit.
This one I also dislike as I (unlike the Dynamo team) know that users are on older versions of Revit. The reason I say that is for any new Dynamo feature, you typically get a response to “update to the latest version of Revit”.
This is the option I like the least (of course), because Rhythm is something I have maintained and worked on for a long time.
But, the idea here is that the last version it would support would be Revit 2024.
This option is incredibly difficult, clunky, and unsupported. But essentially Rhythm would not depend on any DLLs. It would simply find it in memory and invoke it (reflection). This one is not going to happen, but I wanted to mention it because this has been suggested to me on several occasions by the Dynamo team directly. Dynamo Graph Migration Assistant actually uses a ton of reflection because Dynamo’s API changed so much between 2.13 and 2.16.
I might add a poll to this post, but for now, I am just wanting to get my thoughts out there and see what you all might have to say.
I think it is important to mention that package authors generally do this work for free (because we care about Dynamo), and we (unfortunately) receive very little support from the Dynamo team directly. I have had quite a few meetings with the team to discuss the package manager and other topics, but those will only come to fruition in future versions of Dynamo and Revit. Which does not help most users. As you can see in the posts at the beginning of this, most of these users are in Revit 2021 or older.
Thanks for reading, and I look forward to your responses.
So I am making progress on this via view extension and extension (combo of the two). However, this does mean Rhythm will lose the UI nodes. They are significantly more difficult to maintain across versions, so they are gone. Small price to pay for the package to work on 4 versions of Revit (2020-2024)
Video of this in action: https://twitter.com/johntpierson/status/1689409289301966848?s=20