Revit 2025.. Data shapes' UI nodes are not working

I have Iron python installed. Does anyone know how to make the UI data shapes nodes work?
Which one should I install, and use?

Try these:

  • IronPython2.7 (3.2.1)
  • Data-Shapes (2025.3.118) (remove then reinstall)

tried that, and nulls are what I get, Thank you though

Hi @r.sadekKBXY4

Can you share a sample dyn (that failed) for testing ?

Sure. Could you provide your email address?

use forum private messages

did you install these package versions

Best to confirm you have the right versions of the packages before you share anything.

  1. Which version of Revit 2025 are you in?
  2. Which version of Datasahapes do you have?
  3. Which version of IronPython2 did you install?

@c.poupin’s last screenshot will show you the UI for validating your Python and Datashapes versions.

1 Like

Revit 25.4.0.32

Just a thought, Guys. I know that we are trying to fix the problem here. And thanks to you I have high hopes in achieving that.

But the truth is, I don’t think that it is supposed to be that complicated. I am blaming Autodesk here to be honest. I mean the variance of python engines, and its support for packages, and scripts consumes too much time. Again I am trying to raise a flag for autodesk here.

The Forum tells me that I can not upload attachments here since I am a new user so I will try to send it to you via inbox

I will start out with helping you solve your issue. You have not installed a compatible version of IronPython2. Your version is 2.5.0. You need 3.2.1, as was pointed out several times in the thread. No need to send anyone your graph.

I hear your frustration here, and feel it as well (after all I’ve been building custom Dynamo tools rather than simply consuming it for quite awhile now). But think a quick examination of the facts will help explain why you are in this situation.

The team is aware of our pain, and even knew so before it started. They have also put in a lot of work to simplify things. However their hand was forced and it is not possible to ‘just keep shipping IronPython2’ as it was for a few reasons.

  1. IronPython2 hasn’t been supported since January of 2022, which means you are 3 years past the last security patch for IronPython2 and the underlaying Python2 hasn’t been supported since January 1st of 2020 which is now 5 years into the past. 3 and 5 years are lifetimes in software terms, and the number of vulnerabilities in that time span is pretty significant. Some of the companies who offer “extended support” (charging extreme fees to back port what fixes they can but not patching stuff which is unique to the old systems) list 100’s of known, publicly disclosed vulnerabilities, many of which don’t even need you to take action on to be utilized, as such even with the “extended support” the guidance is to use an air gapped system which you (and almost every Dynamo user) do not have.
  2. All core Autodesk products updated from .NET 4.8 to .NET 8 in 2025. This means that the underlaying code referenced by any package needs to be re-worked if it uses any form of DLL. As a different Python library is required. At the same time and to further indicate this difference, Dynamo updated to 3.0 to enable a bunch of new features and tools that are already making a difference. That ‘3’ in place of the ‘2’ means that all underlaying tools are likely to need more rework than they had received.

As a result of those two items a few changes had to happen, or Python would cease to be an option in Dynamo.

However as the team was (and is) aware of the issue they knew they had to help people deal with the changes before they came about. So starting in 2022 the team became rather vocal about the issue and a BUNCH of things were put in place to help out the community at large.

  1. A standalone IronPython2 package was created to help people who could not immediately find time to migrate code and we’re willing to ignore the security risks.
  2. Multiple forum posts were created with Dynamo developers and community leaders helping to solve problems Python authors faced.
  3. In product tooling was generated to help authors migrate from Python2 to Python3.
  4. Blog posts outlining ‘why’ and ‘how’ were written by development team members to assist in the finer aspects of the process.
  5. An in-product warning was produced informing users of the use of unsupported underlaying code when it was present to prevent unintentional risks.
  6. Tools and methods were developed to bulk update the Python engine across a library of graphs or custom nodes.
  7. Several new engines were produced to allow authors to select ‘the one that is right for me’ in order to account for shortcomings in CPython (missing compatibility on a few methods used by Revit and Civil3D) and IronPython3 (delayed too much to be reliable and missing compatibility) and also improved and updated these several times to enable better compatibility or keep it running as Dynamo and Revit evolve.

Now you could argue that the team shouldn’t have provided any intermediate version until everything worked, or that they should have prioritized this over something else, or that the security concerns are overblown (they aren’t). But to claim that they haven’t done anything is frankly disingenuous.

Many of those are aimed at Python authors, which isn’t helpful when consuming a Python based package. But from a consumer standpoint you have two options:

  1. Accept that the underlaying code hasn’t updated, and remove it from your workflow entirely.
  2. Accept that managing the environment together will be painful, but you can make the consumed code work.

Now that all of that is said, I get it - you want the code you’ve been consuming for ages to work. And you are right - it shouldn’t be this complicated. But the root cause isn’t anything which Autodesk or the Dynamo team have done but rather with our (yes I include myself) decision to continue to consume tools which are not evolving along with the ecosystem in which we are operating.

4 Likes

At first Thank you Jacob. My script works now. It seems that I got a little confused between DynamoIronPython Version, and build number.

To be honest I am very humble when it comes to coding, not really my specialization, but really thank you for the time, and effort that you had put to point things out.

I hope you guys keep it up, and find a simpler, and easier way for the unification, and coordination.

At the end of the day we both agree that visual programming which dynamo follows targets people who have very limited programming knowledge, and I wouldn’t exclude myself.

Thank You, again

1 Like

The Dynamo team (of which I’m not directly a part of) is actually doing a LOT of amazing stuff to simplify things. I hope to see some more integrations similar to Dynamo for Forma in the future where we (graph authors) will be able to hear of an issue from an end user, build a POC in a desktop environment, deploy it to the cloud and then send a link for the end user to execute. This is already achievable in a forma context. Last Thursday at about 4:30 I had a fellow Autodesker ping me to ask if there was a tool to check the clearances around each building on a site in Forma. I asked for project access, and then built a graph, deployed it to the hub, and told him ‘run that, it should work on all projects across your entire hub’ and we were done. It 30 minutes to do, with another 15 minutes to post about to the team. No more “hey you need to install this package” or “oh you’re in the wrong Dynamo version” or “oh you have the wrong version of that package for your Dynamo build” or the like… The end user just had to hit play.

To achieve that as graph and package authors this will require we keep all our graphs up to date in terms of security stuff (which if you’re following means that yes, IronPython2 will not be an option), but that’s a small price to pay.