Arch Linux

> Blender is distributed with a static python version

Ugh, that's terrible. Arch tries to de-vendor wherever possible for obvious reasons. Did this problem only become worse when Arch upgraded to python-3.11? Ideally, upstream should get their stuff working with the latest python.

I don't think we're going to use the bundled version of Blender. Can you check whether other distros are doing that? We might change the packaging then. What kinds of scripts break and what's the error?

as far as I am aware all debian based distros ship Blender with it's Python version. Looking at Ubuntu their repository does not show Python as a dependency when installing Blender: https://packages.ubuntu.com/lunar/blender
I talked with various addon-programmers for Blender now and they all mentioned only Arch is not distributing the built in Python, but I can not 100% verify that.
I am not technical enough to understand how much that version has stuff from Blender.org added for special Blender operations with Python code, but because every Blender version relies on the same version, addon makers only target that version for compatibility reasons. I recently had trouble with the addon ZenUV (https://blendermarket.com/products/zen-uv) which is incompatible with Python 3.11. In talks with the developers they can not address the issue before Blender officially switches to a new version that will include Python 3.11. Here is the error messages I get when trying to use said addon:

```
Traceback (most recent call last):
File "/usr/share/blender/3.5/scripts/modules/addon_utils.py", line 369, in enable
mod.register()
File "/home/v/.config/blender/3.5/scripts/addons/ZenUV/__init__.py", line 82, in register
mod = importlib.import_module(name, package)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1206, in _gcd_import
File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
File "<frozen importlib._bootstrap>", line 1149, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 940, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/home/v/.config/blender/3.5/scripts/addons/ZenUV/ops/__init__.py", line 25, in <module>
from .operators import operators_classes
File "/home/v/.config/blender/3.5/scripts/addons/ZenUV/ops/operators.py", line 43, in <module>
from ZenUV.ui.labels import ZuvLabels
File "/home/v/.config/blender/3.5/scripts/addons/ZenUV/ui/__init__.py", line 45, in <module>
from ZenUV.ops.trimsheets.trimsheet_panel import (
File "/home/v/.config/blender/3.5/scripts/addons/ZenUV/ops/trimsheets/trimsheet_panel.py", line 36, in <module>
from ZenUV.ui.tool.uv.uv_tool import ZuvUVWorkSpaceTool
File "/home/v/.config/blender/3.5/scripts/addons/ZenUV/ui/tool/__init__.py", line 137, in <module>
@dataclass
^^^^^^^^^
File "/usr/lib/python3.11/dataclasses.py", line 1223, in dataclass
return wrap(cls)
^^^^^^^^^
File "/usr/lib/python3.11/dataclasses.py", line 1213, in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/dataclasses.py", line 958, in _process_class
cls_fields.append(_get_field(cls, name, type, kw_only))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/dataclasses.py", line 815, in _get_field
raise ValueError(f'mutable default {type(f.default)} for field '
ValueError: mutable default <class 'ZenUV.ui.tool.NotifyToolCache'> for field OBJECT is not allowed: use default_factory
```

Another very popular addon maker for hardsurface modelling advices against the Blender version of the Arch repositories due to the Python mismatch: https://machin3.io/DECALmachine/docs/installation/#blender-on-arch-linux

Their addons offer several tricky operations for adjusting models and some of those features won't work on the Arch version of Blender due to the Python mismatch. These addons are important for speeding up certain workflows when working with Blender and are relied upon by a lot of people depending on their Blender tasks. As it stands the Arch version can not be used and I'd like to not have to bother with having to use the version Blender.org offers for download, but that is currently my only option.

I see. The problem is that this might lead to different problems as the other packages which we link into Blender are built against the modern system Python and not the deprecated one that Blender ships. I believe it might require us to build all the Python deps statically against their Python version which is a no go.

I checked Ubuntu and they require libpython which is in their own version. I have a hunch that pretty much all distros will do it like that because anything else is a giant hassle.

I am sorry I am not that well versed with how packaging works. But would there be a way to include the python version Blender uses on their distributions that way? It would be so good to get the better addon compatibility

So I've investigated this a bit. Blender needs a specific version of Python to ensure best compatibility with plugins. During build time, it depends on the distro version of Python and Arch happens to be a rolling distro and as such we don't usually have old versions of packages around. Effectively, this means I'd have to import and maintain my own old version of Python just for Blender.

Furthermore, all of the other Python libs (and those that need to link against libpython) that Blender uses would have to be built against that specific version of Python. In the end, we would then distribute a completely separate Python ecosystem in Arch just for Blender.
It would be a lot of work and maintenance burden since now I have to maintain all affected packages twice and I just don't have the time to do so.
I already maintain an older gcc version for CUDA most of the time and I know just how icky this can get. From a quick look, we'd need at the very least python310, python310-requests, python310-numpy but probably also some of the less obvious ones that just happen to have Python C bindings that Blender requires.

I've also taken a look at how other distros solve this issue, here's the build for NixOS: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/blender/default.nix For them it's working out fine because they ship many different versions of Python at the same time so they can just depend on the proper version of Python. Mind you, this is still not a static Python build but the appropriate shared version of the system.

Gentoo is solving this by giving users the option to use an older version of Python: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-gfx/blender/blender-3.5.1.ebuild
They also had a bug report on this exact issue: https://bugs.gentoo.org/737388 Then again, Gentoo is source-based which helps in these sorts of situations.

All in all this might be possible if we had more automation in place despite our guidelines but for the time being I don't really see how we can support this.
For the moment, I think a user wanting that would be much better served making a blender-static-bin package in the AUR or just using the official binaries directly.

I'm leaving the bug report open since it's definitely valid and shipping old Python interpreters would be viable if we had the automation to enable that.

Thank you for looking into the issue and understanding the need for this. Sad it currently isn't possible to offer that functionality. I trust your judgement on it being problematic to do. I'll use the official binaries then but I am very glad you took my request serious.