Hi, I’m worried what will happen when this happens? Ideally I just want all my old scripts to just continue to work with updated versions of dynamo that come out with the same packages. Will I have to go through every computer and change a setting back when it becomes default so it works?
You’ll need to ensure users install the IronPython package from Revit 2023 onwards unfortunately. It’s to do with IronPython having security exploits I think, they’re moving away from it given it’s older now.
For deployment of tools I tend to work with pyRevit now as it has stuck with the IronPython2 engine (whilst offering CPython3 as an option as well) and has a lot of stuff built into it such as form generation (a bit like data shapes). Needs tools to be written entirely in Python though, so it’s a big jump from Dynamo for most to make.
First it helps to know why the switch was made. IronPython relies on Python 2.7 to this day. That Python engine hasn’t been supported for over a year, and as a result is a security risk. If an exploit was found in the code or in a dependency in the code, your system would be at risk. If a dependency stops working after a Windows update, you’ll be unable to work with the tool at all (or you’d have to roll-back the update). Think of it like running Windows 7, but you get a less people thinking you’re crazy.
You should also know that Autodesk takes security stuff very seriously. Alot of effort goes into keeping what we ship for you to run as safe as we can. You can check out the publicly disclosed stuff here, but know there is even more stuff that isn’t disclosed, as it was found and patched internally. I typically advise people that if it ever says “security updates” in the release notes, assume you want it, and if it is on that site then you should assume you need it pronto.
Lastly, this should not come as a surprise. Three more things of note:
Now that we have some background on why the change is happening and the history on the topic, it’s important to note that there are options.
Now I am going to preface this last bit with a disclaimer. I am not an infosec expert, and this is not infosec advice but rather a personal opinion. Seek professional guidance if you are not sure what to do in the area of information security.
I would trend towards 1 quickly, editing your library to remove uses of 2 until the package can be removed. Is that a lot of work? You bet. I’ve had a sampling of Python3 edited packages circling my C drive for about 2 years now and I’m not done by any means. But maintaining software of any kind is always more work than building it, and like it or not Dynamo graph authoring is software authoring, you just don’t experience it as such. If my infosec team were to push me to remove this from the environment before I was ready, I’d ask them to first ensure that all other un-supported desktop applications is stripped from the environment (see the current and 3 prior version rule for anything Autodesk, so as of today that means anything older than 2020), and that all publicly disclosed vulnerabilities are fully patched (see the trust site linked above). That will likely buy you enough time to make a focused effort to narrow in on what you need and edit accordingly.
Thanks Jacob, my fear is some people have stopped updating their dynamo packages anymore and there could be nodes that are integral parts of scripts. I work in a smaller company where finding time to keep up dynamo maintenance can be difficult. Sometimes it can be alot, I understand it is an evolving beast and will only become more stable in future and less big changes.
Thanks for your options. It looks like 2 would be best suited for me. Does the IronPython engine download from the package manage install to the usual package location? I can then add it to the master package folder on my server and send out an email with a link that people click to robocopy to their folders.
Also all users at my firm use dynamo through dynamo player. Will they get the “hit ok” message through that?
what will happen to the forms which we wrote in iron python? can we use Kinter in Dynamo?
As brutal of a pill as it is to swallow, I always encourage Dynamo/BIM managers to reduce dependency on custom packages by others over time. Crumple was my own attempt to begin consolidating everything I needed in one place so I could more reliably provide Dynamo solutions to my clients. With the current firm I work at part time (300+ people, 150+ users nationwide) I author a derivation of my own package (affectionally dubbed 'Dynatechtus) in-house for them which we push out using batch scripting and we keep to that package and Data Shapes. It means we have to spend more time developing our own nodes, but at the same time we know that scripts will always work on machines and in a predictable manner.
Yes.
Likely not. Best to test in your environment.
This is a bit of a mix bag; No one code set will ever work forever, and so as a firm decides to “own their own” code they need to realize that this means they are going to have to own the maintenance thereof as well. If managed this is a GREAT solution (even better if you deploy it to the package manager for the world to utilize!). If unmanaged to started ad-hock it can put firms in situations where they’re unable to use everything after a Revit update or security patch. The more ‘guarded’ the code the harder to get fixed too (ie: a DYF edit can usually be made in under 10 minutes by 10-20% of the users in a mature firm; while a zero touch node requires a developer with an IDE stop work on other stuff to compile what could be a simple namespace update…). So as always the ‘scope’ of the effort to customize should be built with your users in mind; after all the change to use camelCaseInputNames in an otherwise totally functioning but old package like Springs can resolve itself quite quickly (in fact you can bulk modify those .dyf files via another dyn or python!), and then be deployed locally to all users saving the need to write any new code. The only ‘difficult’ resolutions are typically zero touch nodes such as Orchid, Lunchbox, and a few others.
Yes I opted to make the packages 100% Python even if I do learn ZT nodes eventually myself, it has to be at least partially exposed to be manageable and leave things to guide users who are curious as well. Funny that you mention bulk dyf edits using Python, I literally just did that the other day to update some paths in the package for easier navigation!
Another motivator behind this is that I’ve seen most large firms either go this way, or go for ‘no packages’ as an alternative, using Python script blocks on the canvas. I found this meant users always dismissed Dynamo as too high of a difficulty curve, whilst if you can wrap them up in nodes it helps users understand the scripts that little bit more. Was a very tough sell (and I still have some renegades who refuse to use the package too of course).
By my count these firms now have to have 4 different libraries of .dyn files in order to keep up with the great many API, Python, and Dynamo changes over the years… or do they just add if app.Version == 2020.0… to all scripts?
In any case… @GavinCrump is certainly right here; if you want anyone else to be able to use it, put it in a package and publish it (ideally to the PM, but at least to a local repository).
Most firms just send out one library of scripts and pray to the gods for mercy I think. At the firm we’re at I build everything against 2020 and build in version checks to all my Python nodes that need them (e.g. unit conversion utils/forgetype ids).
Ok… I’m gonna have to write a clickbait title to get this AU session in next year or something…
BIM Managers hate him! Save hours of processing time with this one weird trick! hint it starts with “save as”
Have not tested this out yet on 2023. Will Dynamo Packages and Scripts created in 2.16 work in the previous versions of Dynamo? So if I update my scripts to work in Revit 2023, and I path those same packages in Dynamo 2.12 and 2.6 will they still work?