I have deployed 20+ dynamo graphs to several offices using a master repository that gets mirrored to the individual PCs. As engineers we have to use all current versions of Revit that are available to be compatible with various Architect’s files. My goal is to have people just use Player to run the graphs. If people do get interested in creating Dynamo Graphs, this is managed by providing the most used packages in the repository so they do not need to install any, and resetting the default dynamo folder setup at each login. I have been keeping tested, working, “not the most recent” packages for each version of Revit in the repository per Dynamo version (2.0.3; 2.3; 2.6; 2.10).
It appears from this post: Revit 2022 - Dynamo 2.10 - Package not showing up and icons missing that good package developers have been keeping the most recent installs working with the previous versions of Revit. I am wondering if I have to keep the “not most recent” packages around since learning this. I started my current method because it was not my experience that packages would work between Revit and Dynamo versions. Have I been wrong?
What is the easiest way to keep graphs working in the various Revit/Dynamo versions?
I would be interested to know as well. It sounds like you are doing something pretty similar to what I’m doing regarding packages, which is maintaining multiple version of the packages.
I had IT set up a script to run a bat script when people boot their computers/the VDI spins up. it copies the files from our Revit drive to their local machine. It works like a champ and allows for maintaining multiple versions for each dynamo version.
We do what @rjcoolpix880 does to keep the packages up to date. I have been waiting for Mostafa to get back to me about an orkestra demo for 6 months.
My question is more about keeping old packages that work, rather than updating to the latest published packages. i.e. for Rhythm
2019=2019.11.7
2020=2019.12.4
2021=2020.2.13
2022=2021.4.2
I freeze the package versions when they work and stop trying to install the newer versions because in the past nodes have disappeared or been reworked. (Not saying this happened specifically with Rhythm, I just have obviously different packages installed per Revit).
The thread I linked to made it sound like archi-lab was publishing new versions that were meant to be updated in the previous Revit/Dynamo versions. I have been avoiding doing this for older versions because it meant re-testing all the graphs again when I already had something that worked.
When I first sent my request in January, there was no Downloads area for Orkestra on the website. I’ll have to look at this again. Just downloaded the software to try locally to see what it can do.
Currently setting up a Dynamo deployment for a +300 person company, and have opted for a different method to the usual. I’m developing an inhouse package likely deployed via executable file in future, currently downloadable and pasteable from a sharepoint whilst it’s in development phase. Using exposed Python nodes to help hide the complex functions, whilst keeping them open for learning for curious users.
Before my arrival most scripts used no custom packages, but heaps of Python (which is how a lot of companies roll that I’ve worked at or spoken to the managers from) - the packageless approach. In my opinion this doesn’t work, and is counter productive. It leads to unmaintained Python code, and scripts that a new user would not be able to understand at face value if they wanted to learn - preventing a culture of computation of emerging without a steep entry curve involving Python and Revit API understanding. An even worse approach is to ‘lift’ the Python code out of other custom nodes insitu on the canvas - both disrespectful to the package managers and then no-one even understands that Python block should something go wrong.
This means we effectively only use 2 packages for deployment for the average user, the in-house one and Data Shapes. For the power users, I keep a separate folder with the following packages (however most of them know how to manage their own packages anyway):
Bimorph Nodes
Clockwork for Dynamo 2.x
Crumple
Genius Loci
Orchid
Rhythm
Spring Nodes
In future my goal is to encourage the business to enable the package to be publicly available for company convenience, but a majority of it is repackaged from my own work with Crumple. This approach is actually fairly common - we have such examples as Wombat (Woods Bagot), archilab_grimshaw (retired, but for a time was company associated I guess) and various other packages and tools. There is always the risk with this approach that the ‘brains’ or architect behind them will move on (e.g. archilab_grimshaw), but if you do it right and involve enough people, it can form a collaborative effort and be de-risked to some degree.
So far I’ve found this to be quite straightforward, although moving away from using heaps of packages is challenging at times (I have to delve into the API often to rebuild/package functions I know exist elsewhere). Version management without the package manager is difficult, but possible. There is something to be said for the excitement factor of giving the company their own ‘toolbox’ as well, users now request new nodes and functions rather than just scripts as a whole. It gives them a wider understanding that Dynamo is not just about building magic buttons, but the intelligent pieces that go into them also.
Having said that, Orkestra is great if you can get your company to invest in it (paid solution) and is the best in show to me of that type of end user/low maintenance solution.
FWIW we’re focusing on improving the notions of Sharing and Give a graph from Person A to Person B and have it work first time in 2023
In this focus we will look to make Custom Nodes and Package use a better experience… I agree that pulling Python out of packages may solve in the short term, but create headaches later on.
Remember everyone: Exposed Python means you have to edit every saved version of that dyn on every system at each breaking update, maintaining a separate folder for Dynamo graphs for each year. Whereas Python nodes in a package means you can edit that package at each release, push to end users on log in, and users can use the same graphs for multiple versions.
Assuming you can track every ‘save as’ of your DYN file’s forever, the amount of work is the same while the user experience is a bit more limiting.
I should clarify, I mean custom nodes that aren’t zero touch. So they are still contained in a package definition, but can be edited and viewed internally if the users get curious.
Ah! Quoted your wrong sentence there. Highlighting with my phone is silly sometimes…
Was trying to show that you were putting the Python IN a custom code which is good. Loose Python = more work in the long term. I’ll try to remember to edit when I am at my PC again.
This! We have been maintaining a folder of Dynamo graphs per Revit year version because newer packages would break the nodes in the older version of Revit. Sometimes the node would be renamed, sometimes it had the same name but all the inputs changed to PORT1, PORT2… and they would not work as they had before.
To remedy this, I have basically frozen all the packages for a Revit year to the package version that was current at the time of the graph publication. The next year when Revit comes out again, I install the current packages that are available, copy over existing graphs, then test and replace all the broken bits to have them work in the current Revit version.
We have completely gotten rid of 1.3.4, so all of these are 2+. Am I getting the message that when the new Revit year comes out, I can update all my packages, fix the broken nodes, and now these graphs will work in the previous year of Revit too? As long as those package updates get sent to the correct folder.
[Edit]: BimorphNodes V4.0 Released - Rebuilt for Revit 2022 - #3 by MartinSpence A post like this I have not seen before. If they existed I missed them. This is very clear about being compatible with previous versions, what issues might come up, why and how to fix them.
I have gone through our pile of graphs in 2018 - 2021 Revit, and found that some packages are backward compatible. That means that the nodes in the 2018 version are working in 2021 as well. But since all of them do not work this way it is not very feasible to manage graphs based on backward compatibility. I think it will be easiest to just have a set of graphs and packages for 2018/2019, 2020, 2021, 2022.
So we are just back to having the packages working for 2019, for example, frozen at that version. The 2020 copy of that package can be updated and gotten to work with any changes, then freeze that one too. This way the previous versions can continue to work with no more work or updating, and when we update them for the next new version, once they work stop updating packages for that version.
that pulling Python out of packages may solve in the short term, but create headaches later on.