I’ve had a user just notify me that an inhouse package I wrote in IronPython/2020 is throwing errors about Python engines in 2022. I uderstand this part, although they claim it’s preventing the script running - skeptical, confirming tomorrow. But it got me thinking…
Is there a recommended strategy in a company working post/pre-22 (spanning 18-22) in projects for how to support them using an inhouse package and script set? I am really hoping the suggested approach isn’t to build two packages as well as 2 copies of each script to pick up those packages (we have users jumping across versions for different projects).
If it is I might just switch to pyRevit for now, as much as I love Dynamo. Due to speed of version release firms simply get bogged in old versions on jobs that go through 4-5 uneventful releases of Revit.
Also is there a prospective date when IronPython will not work in R22 and beyond?
One of the Dynamo team members might need to confirm this, but doesn’t Revit 2022 include the version of dynamo where if you still need IronPython you will need to have the IronPython package installed for them to work?
I’ve been using IronPython until recently so if so it must have been in the latest update unless I missed something. Handy for me to be aware of though, thanks. I will try this out if pain persists and will have to add it to my deployment I guess.
A confirmation from the team members would be great.
Thanks Cyril, I had actually just went back and was watching this to recap and hadn’t quite got to this bit yet - appreciate the time stamp! It turns out there was a package copy/paste issue that compounded with the following message lead my users to think IronPython had bit the dust.
False alarm, but finding out about the package to install is great in the interim.
I would recommend starting the migration to CPython soon. Yes the IronPython package will give you a bit more runway, but keeping IronPython in use is a security risk. I know you can’t necessarily ‘stop’ production of code for 2019 and similar builds, but splitting the package into two versions at 2022 might make sense as it has big the Iron Python depreciation and the Units API changes.
I can already hear the users asking me why their dynamo 2022 script doesnt work in 2021 and vice versa. Ah well, the price of progress! Oh how I wish firms would just upgrade models in sync, or Autodesk would just slow down on the merciless annual cycle and do patches.
If R23 doesn’t bring game changers it’s getting a paddling on the channel next year. Dealing with firms falling behind the 4 year apart rule regularly these days - the problem grows each year.
Having said that, it gives me much more appreciation for the versions dynamo has been built to span between all these builds of Revit.
A lot of offices need some guidance here. Upgrades used to be VERY time consuming, but that hasn’t been the case for 5 versions now. Upgrading Cloud hosted projects is three automation buttons so it is a non-issue, and locally hosted it’s as simple as archive, E-Transmit and overwrite the prior file. Implementing some degree of model analytics will mean you near instantly ID any data fidelity issues resulting from the upgrade. The way I have seen it since before I started at Autodesk: if you are t upgrading you are just being lazy. I’ve softened since joining a bit, but a bit of proactive communications helps (read that as send out the all office email saying ‘time to start planning the upgrade for projects in Revit current year -2 every November first).
Agree it’s ultimately a cultural issue. Just not sure I’m willing to play the role of ‘Dennis Waterman’ here (only makes sense if you know Little Britain - basically the person who does the whole thing - really struggle to get big firm leaders to engage with data analytics, I’m often the one scraping, viewing and actioning data).
The level of digital sophistication software expects from firms seems to be rapidly accelerating which I’m glad for on the one hand, but concerned for on the other. More clients to not take on as a consultant in future I guess!
There are some aspects of upgrade culture we struggle with beyond the internal ‘just do it’ approach, such as reluctance from one party holding the rest back, incompatibility between even sub-builds and archived projects not being on B360 or so far gone that they’re almost unupgradable until our computers are quantum.
Anyway I digress, off topic I go. I have installed the IronPython package for now and decided once Dynamo hits ‘dark mode’ officially I will split the timeline and make two sets, that way users can visually distinguish more easily if they are in the intended build for the package/script.
@jacob.small
You say migrate to CPython - but it’s known that there are issues with CPython and Revit API (pretty major ones in my opinion).
It’s going to be difficult to migrate completely until CPython plays nice with the major platform that most users are using Dynamo for.
Also - you say IronPython is a security risk. Can you explain more about where that risk might be (for us non-IT folks)? Is it a risk just using downloaded external packages using IronPython (but no risk if you are developing for your own use - so Package Authors should migrate but its totally safe for one to use internally to one’s own company)? Or is the risk literally just in the mere presence of IronPython on your machine (so really the better solution would be to get all versions in use with Revit 2019 and newer using CPython and cleanse IronPython entirely)?
