Rhythm for Dynamo Availability: Question for the Community

[GavinCrump]

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.

[Aaron_Maller]

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.

[john_pierson]

@c.poupin

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)?

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”.

[jacob.small]

@Aaron_Maller

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.

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.

[jacob.small]

Very impressive as always.

[chuongmep]

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 ?

GitHub - chuongmep/OpenMEP: A package for MEP, Computational Design,...

[jw.vanasselt]

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?

[Brendan_Cassidy]

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:

Dynamo API - Set User Packages Location

@oliver.green The below seems to work for me. It adds the new path to the Custom Folder, then loads the packages for any “pkg.json” files it finds. string NewPackageLocation = "C:\\Temp2"; List<IExtension> extensions = startupParams.ExtensionManager.Extensions.ToList(); PackageManagerExtension dynamoPackageManager = extensions.FirstOrDefault(x => x.Name == "DynamoPackageManager") as PackageManagerExtension; List<string> CurrentPackagePaths = startupParams.Prefe…

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 ).

[john_pierson]

@jw.vanasselt

but can’t you catch this by reading the revit/dynamo version and using the if statement to determine what the code should use?

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.

[john_pierson]

@Brendan_Cassidy

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 ).

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:

• extensions load first. In dynamo player and full dynamo ui. But loading a library from an extension results in no nodes in the library view.
• view extensions load second. Works great for full ui dynamo but not player. Plus if the extension already loaded the library we get issues.
• nodes libraries load last. And if anything goes wrong with the first two they won’t load at all. So we have to be aware of what dynamo api calls we use.

[Chad_Clary]

@Aaron_Maller

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.

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.

[helena.wahlstrom]

The Dynamo team is working on several improvements to the package experience. You can check out the early work in our daily builds, where you’ll find a consolidated package experience in the Packages > New Package Manager Placeholder (WIP, more improvements to come.)

One improvement we are working on is adding a version picker in the package search that allows you to select a version without having to view package details.

I appreciate everyone weighing in on this topic; please do keep the feedback coming.

[john_pierson]

@john_pierson

Updates

20230809: 4:45pm
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)

Adding updates as I have them to the first message.

[GavinCrump]

I wonder if a handy feature for this is to add a feature when uploading/updating a package to include/exclude a search string for the active revit build. So a package author could say include for 202*, 2023, [2023,2024] etc. I appreciate there are other platforms besides revit here to condider of course, although most adsk apps are versioned by year also and use similar build strings.

This may help packages running wild in new builds if the user prefers to work that way, or they could limit builds to tied versions like archilab and rhythm are trying to.

Food for thought.

[ruben.romero]

I thought reading the post that the creator of Rhythm package of Dynamo is suffering with the updates of the package every time the RevitAPI changes, so I understood is leaving this free job . I try not using packages anymore, try to build by python scripting, good reference though the package very useful and complete

[john_pierson]

@ruben.romero

I try not using packages anymore, try to build by python scripting,

There’s still suffering with Python.

Explaining to everyone to install the “DsIronPython” package is not fun either.

[john_pierson]

@ruben.romero

so I understood is leaving this free job

Abandoning my custom package is not my first choice. It is a choice, but one I’m trying to avoid if at all possible.

Right now I have something promising working. But I need to create a video to explain what it does and to plea my case to the Dynamo team. I’m worried that this new method I’ve developed will “get fixed” in the future. And if it does, that’ll be the last straw for me.

[ruben.romero]

@john_pierson

something promising working.

Consider me as another user more of Dynamo, maybe a bit more advanced level but same thing, so if I don’t know much about Dynamo and no time to invest on it then going to package browser and try to use packages with custom nodes as much as possible to save life time.

The consequence is that the Dynamo graph with the packages worked well for that time but if trying to use same script in future probably revit version and Dynamo version ia different and then i will try to install the corresponding version of each of the packages used to make it work but reality is that i would install the latest version of the same package that let me install the package manager in the version of Dynamo that i am using in the moment. Doing that sometimes the Dynamo script doesn’t work as expected or fails so it’s a pain and end up creating the script from scratch or replacing parts of it.

If the package now is not in the package manager probably many users will not know the package exists and if they know about it, many will stop using it if having to install from an installation file .exe because the company computers have blocked any installation unless the administrator of the system or IT service activates so in my case I stopped using Orchid, Lunchbox because other people can’t use my scripts that contain zero touch nodes from those external Dynamo package installers.

I don’t know what will be the plan for Rhythm but I just explain my frustrating experiences as a simple user of packages.

Python is a great pain not paid and takes ages to make it work and praying it also works in other Revit versions. Keeping using Dynamo because still see results and users not advanced can take use of it as well

[john_pierson]

I made a video demonstrating one of the issues live (with sample code):

Dynamo for Revit is Broken.

In the next video, I will show how I fixed this in Rhythm for other ZeroTouch authors (or the Dynamo Team) to adopt for themselves. For anyone who wants to test the “Rhythm fix”, please install the latest version from the package manager. v2023.8.6

[Thomas_Mahon]

John, unfortunately there is nothing the Dynamo team can do about this since its a value type. I’ve expanded my thoughts below (thanks for mentioning the category problem affecting BimorphNodes in your video; its working in V5.1).

BimorphNodes v5.0.0 for Revit 2024 Released - #2 by Thomas_Mahon;