Hey there, so we’re on nuke 13.2v5 and we’re getting this menu.py error while starting nuke. Normally I think this is a mismatch with python version error, but 13.2v5 should be on 3.7… What can I do to fix this? thank you!
Here’s the output:
Nuke 13.2v5, 64 bit, built Oct 20 2022.
Copyright (c) 2022 The Foundry Visionmongers Ltd. All Rights Reserved.
Licence expires on: 2025/12/30
WARNING: Can't select GPU device NVIDIA GeForce RTX 4090 : 0, using device NVIDIA GeForce RTX 3070 Ti : 0
[2025-12-03 19:45:29,207] MagicDefocus2 is loaded successfully.
Nuke path: C:\Users\dieuw\.nuke
Current path: C:\Users\dieuw\AppData\Local\Ynput\AYON\shim
Traceback (most recent call last):
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\nuke_0.3.13\ayon_nuke\startup/menu.py", line 1, in <module>
from ayon_core.pipeline import install_host
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\pipeline\__init__.py", line 8, in <module>
from .anatomy import Anatomy
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\pipeline\anatomy\__init__.py", line 1, in <module>
from .exceptions import (
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\pipeline\anatomy\exceptions.py", line 1, in <module>
from ayon_core.lib.path_templates import TemplateUnsolved
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\lib\__init__.py", line 6, in <module>
from .local_settings import (
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\lib\local_settings.py", line 586, in <module>
def get_ayon_user_entity(username: Optional[str] = None) -> dict[str, Any]:
TypeError: 'type' object is not subscriptable
Traceback (most recent call last):
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\nuke_0.3.13\ayon_nuke\startup/menu.py", line 1, in <module>
from ayon_core.pipeline import install_host
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\pipeline\__init__.py", line 8, in <module>
from .anatomy import Anatomy
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\pipeline\anatomy\__init__.py", line 1, in <module>
from .exceptions import (
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\pipeline\anatomy\exceptions.py", line 1, in <module>
from ayon_core.lib.path_templates import TemplateUnsolved
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\lib\__init__.py", line 6, in <module>
from .local_settings import (
File "C:\Users\dieuw\AppData\Local\Ynput\AYON\addons\core_1.6.11\ayon_core\lib\local_settings.py", line 586, in <module>
def get_ayon_user_entity(username: Optional[str] = None) -> dict[str, Any]:
TypeError: 'type' object is not subscriptable
You sir - are out of luck. Nuke 13.2 is Python 3.7.7 if I’m not mistaken and I believe AYON’s lower barrier is currently Python 3.9.
The error you’re getting here is we’re using some type hinting that was unsupported in 3.7 but works in 3.9. Technically not the worst of backwards incompatibilities because they are fixable, but I’m confident it doesn’t stop there - or at least not at a few files.
Damnit, but I can’t take out another mortgage at this time to upgrade, we’ve got a bunch of permanent 13 licenses, which is why. Thanks for confirming this though, Roy!
It’s not about Nuke addon alone - any dependency, like e.g ayon-core, etc will need be a potential culprit at breaking compatibility.
You may get by with putting from __future__ import annotations at the top of the .py files that start errorring and see how far you get. But oh boy, then someone uses some other Py3.8+ feature and you’re still fucked.
I’m not saying it’s impossible, but you may be in for a lot of work.
Unfortunately I know a lot of studio’s that are still on nuke 13 because that was when the foundry was last selling perpetual licenses. And I’ve used Ayon with nuke 13 for quite a while in the past years, for support to disappear like this seemingly silently is a bit of a bummer. It kind of feels like an oversight rather than a deliberate choice maybe?
Having to drop support for older Python releases is something that we’ll have to do at some point. I believe the goal was set to support at least three releases back[1] so long productions can run stable - which makes this beyond that cut off point.
The decision to start sunsetting compatibility with Python 3.7 was, in that regard, a conscious choice but without the deliberate intent to generate incompatibilities directly. It’s just that we’d allow Python 3.9 features to be used over time, and we’d be doing the tests with that release as the bare minimum.
So, conscious yes, deliberate breaking no, could this have been communicated better - I think so.
Of course, the product moves based on the community and the clients. If there’s enough weight to keep maintaining a longer support and e.g. community can chip in for older releases it’s not something we’d be super stubborn about. But in practice we’re seeing the majority of AYON users moving along with the product updates. And even if we would put in tons of effort to keep maintaining Python 3.7 for say the next 6 months or a year - the cut off point will happen. Having said that I feel there’s little gains in it now, the amount of effort to support a huge gap in versions grows exponentially unfortunately and the benefit to the users is usually little since the vast majority has shifted since.
We actually have the goal to at least support VFX ref platform up to 2 years back. Which tends to be 1-2 years behind so supporting up to 3 years back is reasonably similar. ↩︎
I get your choice. I’m not a developer so I would probably never understand how difficult it would be for the talented ayon dev team to try and keep backwards compatibility within minor versions of python. In our (relatively small) case it does carry an added burden of a 60k yearly cost, though, for software that hasn’t had any meaningful updates in the past five years, which I know were not alone in, just to be able to keep using ayon.
In the meantime well stick with shotgrid for Nuke then.
If we’d only see 33% of that costs go purely to maintaining this backward compatibility there may be some reason to it - but admittedly I’ve seen no one willing to spend a dime on it. Because once that’s the ask, they’d rather update and get shiny toys.
Happy to discuss what’s possible of course - question would of course also be how much longer you figure you may keep the requirement, and how long that spend then will remain making sense.
Unlike DCCs like these Python updates are free - and they do often bring shiny toys that do make the lives of a developer and the development much better - which on its own also brings a slower overall development pace with it.
Thanks mustafa, yes we’ve got resolve running! One of the big reasons why I wanted to push for ayon over shotgrid And yes I’m aware of those publishing workflows, but if there’s a part of the pipeline where we need exact asset tracking for reading of renders and writes of comps it would be nuke more than anything.
thank you!
But oh boy, then someone uses some other Py3.8+ feature and you’re still fucked.
Because once that’s the ask, they’d rather update and get shiny toys.