Please forgive my ignorance, but one thing that has always mystified me with packages is not knowing how to tell which package version is the latest version for the version of Dynamo I am using.
I have quite a few scripts that have worked correctly from Revit 2019-2023, using the same package versions for the most part. But a few tools have stopped working correctly with Revit 2024. So I need to put together a new set of tools and update the packages to work with Revit 2024 (Dynamo 2.19.3).
Developers seem to do the version numbering differently on every package, so there’s no one rule that dictates which version of Dynamo they work with.
So, is there some trick to knowing which version I should install?
Some of them have a year in the version number. Presumably that would be the Revit version they work with. Maybe? Orchid is 212 and is obtained from its github page, so that one is easy. The others, no real correlation between version numbers that I can tell.
Also, the Package installer in Dynamo 2.19.3 does nothing when “View Details” is clicked. I assume this is where I can see all the version available. So, I’m only able to install the latest version. DynamoIronPython2.7 says it or one of its dependencies is made for a newer version of Dynamo. As far as I know, my Dynamo version is up to date. So this package is built on a nightly or something?
I don’t know. I’ve just always been confused with package version and knowing which I should be installing.
How do you guys go about having different sets of scripts, utilizing different versions of packages, for different versions of Dynamo? We still use Revit 2022-2024 on projects. It would be nice if the same set of scripts and packages could work across all three.
Rhythm utilizes a versioning system called calver. The first number is the current year, the second is the month and the last is the build (not day of month). This offers me the ability to create any number of builds in a given month if need be.
And for version compatibility, the latest version of rhythm handles this on the fly. If you’re in Revit 2020, it just reconciles the correct version for you and so on.
I have a video here discussing it a bit:
Rhythm for Dynamo Installation Updates
30+ builds in a month would be a crazy time! Nice system though, thanks for sharing - can see that being particularly relevant in a coworking scenario with lots of micro updates. Will definitely begin using this in more places vs yy.mm.dd
Outside of dynamo/aec, 30+ updates is very possible. lol.
Also, I’ve had some months where I hit at least a dozen because of changes with dynamo or Revit and I keep testing “live” to make sure my end users are ok.
If I were versioning something for a firm like a template, pyrevit tools or dynamo graphs I would definitely be inclined to use calver.
One of my favorite open source projects actually uses calver as well,
I had heard of Orkestra. I’m trying to remember if I had tried the free tier before. Seems familiar.
We currently use Dyno to host our tools on a custom ribbon(s) (yeah, I’ve done it with pyRevit, too, but that method had too many issues so I moved to Dyno). One of the downsides of Dyno, that I’m not sure if Orkestra solves is that you get to pick one location for all of your scripts for ALL installed versions of Revit. So, if you need a different set of tools built on different versions of packages, Dyno still only lets you select one tool stack. So you have to switch the script path when you open your desired Revit version.
So, I guess the short answer is, I just have to research each package, maybe its website or github page, to figure out which package version works with which version of Dynamo.
Then just hope a new version doesn’t make me completely recreate a script when a node no longer works or exists.
I can suggest to pick the latest version of the published year of a package that are matching with the Revit version in use. If it fails try the previous version.
It’s important to try to control/reduce the number of packages a firm uses/neede. This will make it easier to test nodes when needed in new builds in future.
I generally recommend using packages with updates in the past year or so if you need the package managers to support issues you may face. If theyre older the package managers likely moved on/abandoned/ran out of time
@GavinCrump Yeah, such is the nature of any grassroots/open source/passion project sort of software. You always run the risk of the POOF effect. As in, POOF, they’re gone.
I try not to rely on packages, but I know next to nothing about Python, so I have to mainly use nodes and the OOTB nodes just don’t cover all the bases, or, if it can be done with OOTB nodes, it’s 20 nodes versus 1 with a third-party package.
I think for the most part I’m using well-known, established packages. But if even popular packages like Rhythm can drop nodes, then it’s a danger across the board.
When the drop nodes it’s usually because there is a better (out of the box) solution now, or it isn’t doable in the host application anymore (i.e. TopoSurface nodes in Revit 2021 would need to be TopoSolid nodes in 2027 or whenever TopoSurface is completely deprecated.) In both cases you need to update your tool to the new environment (Revit X+ instead of Revit X), either by using the new package version or the new out of the box node.
In this case it was the UI nodes from Rhythm. I was using nodes like Titleblock Types and Schedule Views. I can just use the OOTB Family Types and Views nodes and still get what I need. It’s just more options to weed through. I was able to fix the scripts that used those nodes, though.
A good UX alternative to get a titleblock is just have the user select an instance on a sheet (Select model element), then get its type. I actually prefer this vs a dropdown list these days,
Yeah, that’s not what this did. Even though it was in the UI sub-category of the package, it really isn’t a Revit UI node. It’s just a dropdown list (within Dynamo) to choose a particular titleblock family type. It’s the same thing as the OOTB Family Types (I think that’s what it’s called, don’t have Dynamo open to check), it just limited the list of family types to just titleblocks.
The goal is a permanent selection of a family type within Dynamo, not to have the user select a type.
So I found my UI bug. It was on my end. I was writing the RhythmRevit.dll twice with my view extension, once named as RhythmUI, resulting in no UI nodes.
I apologize to Dynamo for blaming it for my mistep. lol
