ClockWork 2.x is used in one of our scripts
It’s Element.CurtainGridLines.dyf
we are using it for automatic dimensioning.
But it still relies on Python2
so as the company migrates from 2020 to 2022 a few of the previous scripts are breaking…
Are there suggested replacements to try or a timeline for Clock Work's next update?
I did see activity on their github repo that suggests they were removing python 2, but it also doesn’t appear to be published yet…
I saw a mention that some of Clock Works plugins are core to Dynamo now, but I didn’t notice this one on the list.
If I just edit the .dyf to run python3 is that enough?
or would it conflict with the rest of ClockWork?
That migration is going to more than likely be a little more difficult than “upgrade to CPython” because some of the nodes will need to be tested.
What is even more troubling is, with 2.13 on the horizon, lots of Python custom packages are going to need updated. 
2 Likes
don’t forget that you can install the ironpython 2 package to get the ironpython 2 engine back - if it is for a critical workflow.
workspace references extension should even recommend it in some cases - does it not in your case?
4 Likes
I think in this case, we still have access to ironPython (Dynamo 2.12).
1 Like
I’m still relatively new and trying to patch scripts I’ve inherited from their previous developer, I’ve not seen any such recommendations yet. But telling Dynamo to keep using python2 a bit longer seems to have kept most of the scripts active for now. Thank you for your help
1 Like
Yep it’s a good point and a big pain for most package managers I’d say, and I expect once firms are actually on R22 will be a common issues thread on the forums (like the excel/windows update is now).
CPython is great and all but comes with a lot of quirks and to rewrite packages will take a while. Unless Cpython is worked back into pre22 builds I’ll probably be caveating my package with ‘youll need the ironpython package too, sorry’ unfortunately, as I still mostly deal with R20 given many firms are still down there I deal with.
One of the drawbacks of shackling D4r to Revit is the backwards compatibility slide as well, but I get why they moved in that direction. I’d be more likely to just to ZT nodes versus rewrite to package versions in python. Will be interesting to see what others do generally, especially given for many developers their packages are side/passion projects at most.
6 Likes
Funny enough. This is the exact reason I went from dyf based nodes to zerotouch. (2.x not backward compatible to 1.3.x)
6 Likes
