After installing the DynamoIronPython2.7 Package (tried the latest and penultimate version), a simple import traceback currently hangs in Revit 2025 with Dynamo 3. The same applies to some other standard IronPython components that are imported.
Do more people suffer from this?
Solutions are simple. You can add a sys.path. And if possible, you can -try- convert the script to CPython. But previous Dynamo versions did not suffer from this. And this seriously hinders the reuse of old scripts by less experienced users, or when in a hurry. 
Is this something to report on Github because itâs a real bug? (p.s. the latest version of the package is not compatible with the linked version of Revit 2025)
Or are there also smart solutions from the user side?
In any case, I want to avoid having to search through all the big and small scripts for IronPython nodes to make manual adjustments. 
1 Like
No need to search - and in fact you can swap the IronPython engine for the new one and most code will work fine, and do so in bulk. This thread and the linked file(s) should help there. Updating python node in multiple scripts - #15 by jacob.small
Once upgraded just run the test and save those which donât finish correctly in the âto updateâ directory, and those which run without error in the âready for releaseâ directory. Once testing is done update the failures in the to upgrade folder, saving them in the âready for releaseâ directory when done. Once the âto upgradeâ folder is sufficiently emptied deploy to production and move onto the next task. 
1 Like
Thanks Jacob
At the moment the inability to load normal IronPython libraries without any Ă©xtra work, (Having to add a new library path or change a scipt to CPython or do smart things in bulk) is a problem for us. From our point of view this is a huge bug. And the mayor reason to prevent our company to use the new Revit 2025 version. We will wait for upgrades. Because we have time to wait, but limited time to make things ânicerâ when it did work before. It is harder to sell that kind of time investment to my CEO.
In the meanwhile we wĂll dig a bit further into CPython. (We understand the need. But know that it will also give new problems) And we will change whatever we can âon the flyâ to make things future proof.
I will also check your thread. Great work there. Appriciated.
Any kind of production program requires an investment in maintenance or a decision to not do so and remove it from production and archive it until you have a need. This has to happen annually at a minimum. You might not have realized it, but Dynamo is programming - visual programming has programming in the name after all. As such before any of us wrote a single line of code or adopted a single package we should have considered the maintenance load. Sadly none of us (or nearly none of us) did so.
Your CEO would certainly not want you using IronPython 2 (what you were using before), and would likely approve âmaking things safeâ by porting to CPython in a hurry if you bring it up. IronPython 2 hasnât had even security patches for years now (a lifetime in computer speak), and there are a few CVEs which might apply in some way which means there are known vulnerabilities that wonât be addressed until you update.
Fortunately you might have noticed that the Dynamo team will be putting some time into making the Python integration, but perfection is likely a ways out and nothing is certain so your company should take itâs own proactive actions.
Thanks Jacob for the feedback and the link to the road map.
I just ranked the Python Integration on the road map. This is important to us.
Because Iâam upgrading Dynamo since roughly 2017, we do have some yearly resources for upgrading. And our workflow in Dynamo, Package use and Python scripts does have some flexibility because of this experience. You are correct that maintainace and testing is truly underrated by everybody. 
No doubt I miss some deep insight in programming. That is one of the reasons we love Dynamo for help with small and some bigger tedious tasks in Revit.
For now, my main question is why importing (e.g.) traceback in IronPython2 in Dynamo 3 with the DynamoIronPython2.7 package installed, does not work. Unless I add a new library path located on my C drive. And do not use the normal version. It feels less save. And it does not make sense. Also because it did work in all previous versions.
Is importing traceback unsave? It does seem to work in CPython. Or is importing IronPython2 libraries at all unwanted from the site of Autodesk? Is it save to add a library path to my local IronPython2 install, instead of using the one shipped with Dynamo or the DynamoIronPython2.7 package?
It would help me a bit further if I get an answer to these questions.
At the moment it feels like a bug in the DynamoIronPython2.7 package for Dynamo3 as far as i can see.
Well, my best guess is because the IronPython2 package isnât completely supported for Dynamo 3, and as itâs nearing 4 years out of support itâs unlikely to be fixed (the effort would be better spent on making the CPython or IronPython3 engine more robust).
At this point itâs been almost 4 years since CPython was introduced to Dynamo (both it and Dynamo 2.7 will be 4 on July 15th), and no supported version of any product I know of shipped with the IronPython2 integration - the band aids have persisted despite many in the community encouraging people to âmigrate what you can to CPythonâ often. Most scripts migrate without issue, and often those which donât usually want to be shifted to a more stable language (C#) for security, reliability, stability, and supportability reasons.
1 Like
Ok. I will see and give it a try. Again. And if I have found time from my actual work.
The loading of a normal library does work in CPython. Thatâs true.
Still checking a script for some changed API classes and methods is different from changing the whole language. But after checking at least we know more specific which script breaks.
Stil not sure what I want to do when a script breaks. Learning how to make it work in CPython. Removing the script at all. This feels like a loss. Use the quick escape by adding the Python Path to a local IronPython version that does work as it did. This is a strange solution, based on our conversation. Or rewrite it in a different (new) language. Weâll see.
But until all our main scripts and related Packages work, no Revit 2025 I think.
Hi,
For bugs, you can report them here
Then, you should know that Dynamo is working on an update of the CPython engine
with the integration of PythonNet3 (instead of PythonNet2.5) which fixes a lot of bugs
For the Revit 2025 upgrade, if I could make a suggestion, it would be this
- start migrating all your scripts to IronPython3 (or CPython3 - itâs simple python code), the fixes would be pretty much as follows:
- Python3 syntax correction
- remove unnecessary bits of code linked to the previous version of Revit (example:
if revit_api < 2023: do_this())
- Moving from .Net Framework 4.x to .Net 6+ (e.g. changing Naming Spaces, modifying or replacing COM interrop, etc.)
*at this stage, you can already start working with Revit 2025+ and have got rid of Python2.7
*
- Once PythonNet3 has been integrated into Dynamo, if possible, you can gradually switch over to Python nodes to CPython3 engine, with the following fixes:
- Switch from IronPython3 to PythonNet3 in terms of syntax (out Parameters, Class Interfaces, etc.)
- Possibly code some libraries in C#, if PythonNet still has bugs in certain functionalities.
This means that youâll have to dedicate scripts for Revit 2025 and beyond, but this is a changeover, so you might as well start with ânewâ scripts.
In my opinion, it is one of the least energy-consuming processes
In all cases it is interesting to follow the developments of IronPython and PythonNet
2 Likes
Thanks Cyril for the feedback.
Iâm not really running. Maybe hide a little from unnecessary work.
And the narrative remains a bit ambiguous around the security and future-proofing of IronPython2. Perhaps similar to the climate. Things are changing, there are risks, but things are still going well. Something like that.
But weâll dive in⊠when we can. And try to find the best migration workflow / tools for us. And also waiting a bit for others to join.
Creating dedicated dynamo scripts and packages is what we do every year. That is indeed a good way of working
1 Like
the problem is that Iâm really not sure that Ipy2 (Ipy2 is no longer maintained) is compatible with future .Net versions (Ipy2 is getting old)
1 Like
Let me remove the ambiguity here:
- Iron Python 2 Is Not Secure.
- Iron Python 2 Is Not .NET 8 compatible, so things WILL break.
At this point (4 years after the launch of CPython) anyone writing new code in Iron Python 2 is re-arranging the deck chairs of a sinking ship; sure youâve come up with a better layout, but perhaps itâs time to make our way to the other boat?
6 Likes
I believe itâs almost time for the package manager to have a way to not show certain packages unless you opt in, particularly those provided as bandaids by the development team. If IP2.7 is not recommended for 2025 maybe itâs time for it not to appear in the package manager for this build too. I appreciate itâs a bigger challenge/consideration to modify how the package manager works, but it would certainly help make it more navigable (and it sure could use a deep clean/nuke at this point anywayâŠ).
1 Like
make no purchasing decisions, butâŠ
Filtering packages by version is actually something the team has discussed, and updating the package manager is something on the roadmap. 
7 Likes