once Lunchbox was removed from the package manager we used it a lot less, in theory that shouldnât be the case but unfortunately that was the case. Even though it seems like that is one of the better options.
Or just support the latest. Which is unfortunate but sort of what Autodesk/Dynamo sets you up for with how the versions work. I agree with @Aaron_Maller though, we work primarily in 21-22 at the moment. We have some work in 23-24 but not much.
@john_pierson I think youâve got a major uphill struggle since you depend heavily on Dynamo and Revit APIs and with the myriad of changes occurring not to mention the coverage your package has over many aspects of the various APIs your options are limited.
In all honestly, I would let go of the idea of having one package to serve them all and do what say Clockwork did when 2021 changed the unit types, and release a Version 2024 of your package. The reason why I think this is the best option in your case is because of a major clanger (IMO) from the Dynamo team (which also affects BimorphNodes - Iâll explain more next) which means, even the solution I suggested on Twitter wont work. It does work for Revit however. The next problem is the fact your time isnât free yet a lot of time goes into package development so maintaining two versions is going to be a nightmare.
The clanger BTW is the fact that Dynamo uses longs - a value type - to represent represent ElementIdâs - a reference type - in the Revit API for 2024. In previous versions its an int and therein lies the problem. This isnât a problem so much if its internal in your code as there are workarounds, it is an unsolvable problem however if you have any nodes which return ElementIds from Dynamo types since its a type change rather than a change to a property in the type (i.e. Revits ElementId using a long instead of int in 2024). Therefore, there is no way to handle this problem, unlike Revit API where dependency injection can be used - its what BimorphNodes does.
I suppose you could box the value meaning all outputs returning ids would need to change to the object type but that brings with it a type change that will break all graphs using your previous version and create new problems in the future as the type is ambiguous. If Dynamo API had created its own wrapper around ElementId this wouldnât be a problem. Nobodyâs perfect. In BimorphNodes, this problem affects 1 node and my plan is to depreciate the node in the current version and hide it in future versions since other nodes can provide the same result - washing my hands of the problem essentially - and this is why packages with lots of dependencies on the Dynamo APIs cant do this and why releasing a new version is most likely the only option.
Iâm still going to publish a article explaining in detail with full implementation details and code snippets to expand on my twitter post, I just donât know when this will be as Iâm snowed under with project work at the moment. Iâll aim for first week of September. You could solve a lot of problems with bar the issues with the Dynamo APIs - the alternative is to remove any node returning element Ids or anything else which is a reference type in Revit but a value type in Dynamo and weather the storm of breaking changes it will create. At least you can stick to maintaining and publishing 1 version which is best IMO irrespective of the shortcomings of the package manager.
Thanks for the reply @Thomas_Mahon . Definitely looking forward to the sample, but no rush at all!
As a company Dynamo Admin (and not an active package developer), I like the Orchid way (Option 1) without the package manager. If you have an admin who deploys the packages&scripts by robocopy scripts in the autostart folder to all users machines, this is the best way, because users cannot download other package versions in the package manager and you know that the company scripts are working most of the time.
I would upload just a node to the package manager that provides information of how to install the package with the Zip files and where to download the ZIP file with the different versions.
Btw, I think you donât have to use the Orchid exe file, you can just copy the files from GitHub to the right folders.
In my experience, many users donât understand how Option 2 works. Students and Single users most often use the latest Revit Version and luckily it just works. If the UI of the package manager would support a system with multiple Revit Versions, it could work much better. But atm this is just a mess, because if you have the latest package version 2024 at the top, you can be sure, that at most companies the users will be downloading the wrong package version for Revit, because they use Revit2021-2023.
My hope is, that one day the Dynamo Scripts and packages will be integrated with Unifi and can be deployed by admins for the whole company by version selection and with one click 
PS: We still use Revit 2021 but preparing for the switch to Revit 2023.
Hi John,
I feel this pain too. Actually Iâm working developing packages for my clients.
The solution that gives me few concerns about version maintaince was Option 2 for specific Dynamo versions, not all.
Revit 2020 â Dynamo 2.3
Revit 2021.1 â Dynamo 2.6
Revit 2022.1 â Dynamo 2.12
Revit 2023.1 â Dynamo 2.16
I provide an installer that deploys tha package 
to this versions.
As a user, all beit more in the Sandbox than in Revit these days, I agree with @Aaron_Maller he pretty much hit the nail on the head. I have a little different outlook on option #3, but other than that hit that nail right on the nail right on the head 
I also use the archi-lab package, and the way I deal with that is to just create a â2021â or whatever year Iâm using folder and put the packaging in there. Then I only add that folder path in that version of Revit (so Revit 2021 only sees the â2021â folder, and Revit 2022 only sees the â2022â folder.
For option 3, only supporting current version, as long as you donât remove the past versions I donât see a big issue with this. Yes some people will hit download and get the âwrongâ version if they are still on Revit 2021. But in reality if they are still on Revit 2021, they likely donât want the latest and greatest anyway because they are on an old version of Revit and an old version of Dynamo. They have a graph that works and the less changes the better. Running the latest version is great for testing and new features, but not great for product, that ship doesnât turn on a dime as we all know.
In the end @john_pierson I vote for whatâs the least work for you! You have done so much for this community and given so much of your time and yourself it is just not fair to ask for any more from you! 
This is why itâs so great that youâve made this package open source so others can learn from it and take up the charge to improve it and move it forward.
Hi,
I donât know if itâs doable, but is it possible to download & install the right versions of the dll and xml at the end of the package installation via an event (installation package finished)?
Which would amount to making a version by version of Revit âOption 2â (maintaining only the latest version) but with a single Dynamo Package which acts as installation management according to the version of Revit
respect and courage
It is actually fairly possible if I do that within the view extension.
However, Dynamo gets kind of silly with any DLLs hanging out in the extra folder and will latch on to those as well. So I would need to do some gymnastics to download it on the fly.
It also doesnât help a Dynamo Player user who mightâve downloaded the zip from dynamopackages.com
However, this might be the option I entertain first.
Option 4, deprecation actually means ceases to exist at all. Thatâs why its my least favorite
Just use p⌠jkjk
As a Python package developer who has largely run out of time to maintain let alone subversion I think for most people lacking the level of dedication you do to your package the stance for many has been to draw a line in the sand at 2022 prior to IP2.7 deprecation.
RE Rhythm specifically, a git approach and soft install via package manager would only change the types of headaches this gives you based on the confusion Iâve seen Orchid generate. I literally stopped using it in videos as all questions became about how to install Orchid. I believe users not able to run installers is wild but it is what it is⌠food for thought.
I think the clockwork approach whilst unfortunate in having to drop support eventually for lower builds is most in line with how firms version. So a version of Rhythm that stops development at Revit version 2020, 21, 22 etc. might be an approach that lets you focus on latest/greatest offerings versus spread your focus thin. Realistically Dynamo pulls a lot of weight in project setup and production, particularly Rhythm. Maybe the option is to clamp the offering it gives per version at points in time?
If this does happen Iâd suggest actually making the legacy packages Rhythm 202X in name so its super obvious which is installed. Most users just slam install and donât seem to understand the subversion systen ala archilab.
Something on PM to direct and help deploy is kind of a must for your work to scale to customers who arenât in direct contact;
With respect, i dont agree with this. Look at the app ecosystem: There is an âAutodesk App Store,â and of all the apps we use, i think MAYBE three came off the app store. The rest were all downloaded straight from the manufacturer. Nothing is inherently âbetterâ about the ones coming from the App Store, either. The Package Manager may be convenient because its âon the flyâ but that convenience is superseded by the fact that its CAUSING a lot of the hardships.
Most (nearly all) companies donât manage shared parameters or families across the org (never mind Dynamo packages and graphs), and VERY few do so as well as @Aaron_Maller does (
sarcasm: going forward all graphs I send to him will have a node in custom package that isnât on package manager but is absolutely integral for functionality of the graph /sarcasm).
On this, we agree. And thats the point: If an organization (even like ours) is frustrated with the complexity of it, the status quo doesnt work.
I also think- in trying to solve some of these things- the Package Manager (and the newer extension for Packages/Dependencies) are making things worse: Like, i sympathize with what this dialogue is trying to do:
Hey! Someone put the node in with an older version of Rhythm, but this isnt the right version of Rhythm! What should we do?
But guess what its actually done? Its desensitized us to even checking this dialogue, because i know if i start selecting options from that, i might get a dumpster fire reaction. Well, and it wont let me do it anyway, as itll want to uninstall the other rhythm, and- oh, oops- now restart Dynamo and try it again, etc. Allthewhile it SHOULD be asking âis the node working correctly? If so, it doesnt need to warn me here.â I know thats a tougher ask, but here is the reality:
Developers like John are getting forced to keep releasing updates, and⌠now were warning users because a developer released an update? So now were teaching users to ignore warnings about updates, because⌠everyone has to update?
The more i think about it, the more im looking forward to more of the good package developers releasing their own installers.
Researching this a bit, and it does seem possible via an extension (not view extension).
For those who want to follow my coding progress, see: https://github.com/johnpierson/RhythmForDynamo/blob/rhythm_version_fixing/src/RhythmExtension/RhythmExtension.SharedProject/RhythmExtension.cs
The downside is, since it is an extension (viewless) the package doesnât show in the library at the moment. But I will figure that out next, then we might have some âbeta testingâ. 
Sure. But those apps in any environment are a complete solution; you could put a bundle together with dyns and custom nodes and deploy that via an installer. But when person X asks for the dyn for the cool thing and you send them that but not the package it becomes a ten touch point merry-go-round of sadness and frustration via emails/calls/messages. Finding the package
has been thorn in many a Dynamo userâs side - we used to get a âwhat package is this fromâ post a week - we now go months without them. That alone makes having a package manager worthwhile.
Dynamo graph authors (ie: users of this forum) need a way to consume content from other developers just like the add-in app authors do (nuget) and Python authors do (pypi). However those add-in developers have the benefit of their utilized packages being bundled and deployed with their solution via dlls and such. That system isnât perfect (see DLL hell), but it works. However dyns and many other runtime compiled languages donât have that luxury, and the environment has to be configured before it is executed. In such environments thatâs on each author who is utilizing such packages.
On the good news front, currently the Dynamo roadmap hints at âpackingâ the dependencies into your graph. That would make it possible to share a dyn and have it work as the dlls, dyfs, and all the rest of the dependencies will be âembeddedâ to the file. If things get to that point then a redirect method on the package manager becomes unnecessary - authors will set up their own environments as they want, and users will be able to use deployed environments or just run graphs with the embedded dependencies provided by others⌠Hopefully it will be improved in other ways too (ie: Package manager limiting things to the host application you are searching with; workspace dependency manager showing of the package works as is; etc.), but all things beyond tomorrow morning are unknown.
So while we can hope and see glimpses of a great future, today we have a imperfect ecosystem with three separate user groups. And the consumers and authors of dyns who utilize Rhythm and want/need to share with people whoâs environments are not standardized really benefit from the workspace references manager and package manager as they currently work. Hence the preference for a package containing a node indicating how to get Rhythm installed, even if all it does is open a web page in your browser.
In any case, I support John and any other package manager to do what is best for them. Any sort of packaging of content is a gift, and I am grateful for the work he and others do.
Very impressive as always.
To be honest, I released a package without dependent on any package manager, easy to maintain, I supported more than one version, supported sanbox, supported revit, supproted civil3d, why not ?
Hi John,
Good question!
I have no experience with building packages, but canât you catch this by reading the revit/dynamo version and using the if statement to determine what the code should use?
With you having Rhythm split by revit versions you may be able to have them in the extra folder or downloaded on a case by case basis. Then you could utilise the Packagemanager api to load the specific version you want to load into dynamo in the instance where it has just downloaded the files.
Here is a example of code that will load a custom folder then it will go through the folder and load each package it finds:
Note: You could probably re-use the first section as part of a checker to make sure the right dll/extension is not already loaded into dynamo.
Therefore you could do some Dynamo or Revit version checking then get the specific package from a sub folder or download it then load it in. Just hope on any further dynamo opening it does not cause any issues(we can hope ).
Unfortunately, no. The moment you reference a certain API, your package is dependent on it. So if you reference Revit 2024, the package simply wonât load on older versions (depending on the API calls you use). This is why you see posts like this,
âWhy is Rhythm missing nodesâ.
Will make a video demonstrating with a minimal reproducible case for those curious.
Yep! I currently have code doing something similar now. (Note: I donât want to change anyoneâs package paths at all, so Iâm loading the appropriate DLL on the fly)
Orkestra actually does a lot of manipulating of the package paths on the fly and if something goes wrong you might be left with a mapped folder you didnât expect. (Not saying that happens often but it can happen). That would surely result in numerous posts like, âwhy are no packages loading. They are in the app data locationâ.
The thing with loading DLLs on the fly is Dynamo player is a big consideration and having it appear in the library correctly. It uses an extension and a view extension to do it.
So far Iâve realized:
The advantage of an App Store / Package Manager is that everything is in one place. I donât have to track down 15 different vendors to update software. I can sign-in, go to My Downloads, and see everything Iâve downloaded AND if there is an update available in one spot. I wish I was as organized and neurotic (said with love 
) about how I keep everything in-line and updated, but Iâm not. If developers had a convenient way to download updates in one spot on their website it would help, but not everyone does. And forget about a new user trying to find all of the packages that are almost necessary to be productive without a package manager.
Dynamoâs biggest strength is also one of its biggest weaknesses: user created content (packages like Rhythm) is a huge part of it, especially for people like myself that are not in it all the time. Losing packages like Rhythm or Clockwork would be a huge hit.
