AYON Launcher on Python 3.9 vs Blender Addons on 3.11 – How to Structure This?

Development
,
1

Hey folks – moving this here from Discord as requested and adding a bit more context.

Context

I’m trying to integrate our internal Blender tools as an AYON addon.

I’m new to poetry (I’m mostly familiar with rez, where I’m used to cleanly separating prebuild/build/postbuild/run environments).

  • AYON launcher wants Python 3.9
  • Our Blender tooling (including compiled .pyd deps) needs Python 3.11 to match Blender’s Python

From what I can tell, I effectively have to lock into a single Python version across the launcher and all dependency packages, which is where things fall apart for DCCs that ship with their own Python.

What happens right now

1. Building the launcher (host Python 3.11):

>>> Detecting host Python ... WARNING Version [ 3.11 ] is unsupported, use at your own risk.

*** AYON launcher supports only Python 3.9

So I rebuild the launcher using Python 3.9, and upload it to AYON.

2. Building Blender dependency-packages (Python 3.11):

After that, I switch to Python 3.11 to build Blender-specific dependencies (so wheels / .pyds are compatible with Blender). When I try to do this with poetry, I get:

Current Python version (3.11.9) is not allowed by the project (3.9.13).

Please change python executable via the "env use" command.

So poetry is enforcing the 3.9.x constraint and refuses 3.11.

The actual question

For those of you shipping Blender (or other DCC) addons that require a different Python version than the AYON launcher:

How are you working around the Python-3.9 launcher bottleneck?

Are you:

  • building DCC-specific stuff completely outside the launcher/poetry world and just shipping prebuilt artifacts?
  • running multiple poetry projects?
  • or is there a recommended pattern I’m missing for mixing 3.9 (launcher) with 3.11 (Blender) in an AYON-friendly way?

Any examples or pointers would be super appreciated.

1 Like
2

Just trying to rephrase your post to make a TL;DR;

If I got it correctly, you want to create a new addon with special dependecies that are required for your tools and blender version which typically added in client/pyproject.toml with in your addon. e.g., like core’s addon ayon-core/client/pyproject.toml.

Personally, the way dependency packages work confuses me where client/pyproject.toml from all of the addons are merged into one big pyproject.toml then dependencies are resolved, downloaded and packed into one package.

Why it confuses me, because not all apps use the same python version.
e.g.
Houdini 20.5.370 on my machine is using 3.11.7, so it may occur that a dependency specified in the toml file is not compatible with the python version in my DCC knowing that we support a ton of DCCs so to have generic dependencies that work for all of that is not quite easy.

A great example is Qt bindings dependency for different apps.
we don’t ship them within dependency packages but rather provide a hook that tries to install it directly into DCC’s environment. e.g. Blender PySide Install Hook.

So, until the UV thing is implemented in all addons, I think you’ll need to follow a similar approach.

Further Reading: