I recently upgraded Dynamo and Revit to 2015 and 0.7. After extensive testing on a number of previously working or nearly working modules, I’ve come to the conclusion that, besides some minor alterations to the API due to 2015, the vast majority of code has been made useless by the move from 0.6.3 to 0.7. I now regularly expect such ridiculous errors as “expected Document, got Document” and “expected ElementType, got ElementType” where once there was working code.
I understand there has been a great deal of emphasis placed on Code Blocks, however, these don’t appear to give access to the API in the same way that the Python Script does, and even if they did, I’m not interested in learning another scripting language when I already know Python. My question then: is this a temporary oversight due to the other sweep changes that took place, or should I expect the interaction between the Python Scripting node and Revit to remain as unusable as it currently is, moving forward.
I’ve begun investigating how to move my code from Dynamo to the Interactive Python Shell, but am finding a number of useful features that Dynamo provided to be sorely missed.
Thank you.
Can you post a specific code example and an error that its throwing. I think people will be able to better address your concerns when you do that.
Thank you,
Well, the problem is that it’s not just one bit of code; everything seems to have broken. For instance:
import clr
clr.AddReference(‘RevitAPI’)
clr.AddReference(‘RevitAPIUI’)
from Autodesk.Revit import *
import sys
dataEnteringNode = IN[0] #where IN[0] is Element.Document node
OUT = UI.UIDocument(IN[0]).Application
Produces the error: Warning: IronPythonEvaluator.EvaluateIronPythonScript operation failed.
No module named threading
Where the threading module is only used on a completely different node, and is successfully imported and methods executed…
Trevor, have you had a look at this document already:
Or more specifically, this one:
Andreas, I know I spotted the first link, but must’ve skimmed over the second, much more in-depth description of changes. Thanks for pointing that out.
Unwrapping and wrapping elements, especially, seems like an extra layer of complication. Additionally, it looks like there’s a whole slew of new libraries and methods I’ll need to utilize to get things working again. Can anyone who uses a lot of python scripting speak to ease of use and whether this adds anything or is simply a complication?
Well, I guess it’s safe to say that it doesn’t simplify anything for those of us that make Python nodes. Having said that, unwrapping and rewrapping can be done with more or less minimal changes to your original code in most cases, so it may not be a big deal at all. IMHO, you should be aware of the following issues, though:
https://github.com/DynamoDS/Dynamo/issues/1909 (UnwrapElement doesn’t process lists. Recently fixed in daily builds - and there’s a backwards compatible fix for the official 0.7.1 release.)
https://github.com/DynamoDS/Dynamo/issues/1887 (Migration removes lacing setting inside custom nodes. Only an issue if you have non-Python nodes in your custom nodes as well, like me.)
https://github.com/DynamoDS/Dynamo/issues/1698 (Nodes nested in custom node return null. Only happens in some cases, though.)
https://github.com/DynamoDS/Dynamo/issues/1770 (Python errors now come without line numbers. Makes debugging just that little bit more interesting.)
https://github.com/DynamoDS/Dynamo/issues/1727 (Watch node returns null inside custom node. Also quite helpful when debugging.)
I decided to first do all my non-Python packages first (or at least those where the Python script doesn’t interact with the Revit API), so I can’t give you an estimate of the amount of pain (or joy) you’re going to find yourself in. That turned out to be a splendid idea because I am using it as an exercise to sharpen my DesignScript skills by recreating all of my (non-Revit) custom nodes using mostly code blocks. My hope is that by the time I’m done with that, at least some of the above issues have been fixed and I can move on to tackling all the Python stuff.
And most importantly: It may make sense to have a look at the new Lunchbox version (and compare it to the last 0.6.3 version) as Nathan Miller has updated most of his stuff to 0.7.1 already and there’s a lot of Python in there. That should give you a pretty good idea of what to expect when migrating your Python stuff.
Hey Andreas,
I know that Steel has put in pull requests to fix both the watch node null in custom nodes and the python line errors bugs. I am not sure if these have been merged yet.
Another workaround, which I would like to see as an OTB node is debug.log, you can use python to access the dynamo logger and log directly to the console from custom nodes. I have not tested this on .7, but I think it should still work fine.