Python 3.7 requirement

I frequently encounter build issues because Blender depends on a fairly recent version of Python 3. For example, Ubuntu 18.04 LTS and CentOS 8 ship with Python 3.6, which requires to manually install python 3.7 to build a recent version of Blender. Further, there are already plans to introduce Python 3.8 which will then break compatibility with Debian, another long-term supported Linux distribution.

Are there sensible reasons to depend on features of the most recent Python version?

Which exclusive Python 3.7 features are currently in use that justify upgrading Python versions and potentially breaking compatibility with user code? And which features of Python 3.8 are required for future Blender versions?

If these features are not required, it would be beneficial to make those optional and enable building with older Python version.

We’re gonna stick with 3.7 for at least the rest of this year .

4 Likes

Blender ships with its own version of Python, so for normal users it does not matter what the system’s Python is. If you do development work, it is easy (and even recommended) practice to make use of virtual environments / Anaconda environments.

What would be a reason to not upgrade to have access to new features? As a add-on developer, I’m happy there is support for Postponed Evaluation of Annotations among others. And upgrading between minor versions in Python 3.x is usually problem free.

Does this also hold, if a user wants to use the Blender bindings and other third-party packages, e.g. those at PyPI? If Blender switches to Python 3.8, a user has to install these additional packages within Blender’s Python environment. Or am I missing something here?

Of course, if there is a frequently requested feature, it makes sense to upgrade the version.
However, the general policy should be that upgrades are well justified and not a result of simply depending on the most recent version just because it has the highest version number.

Does this also hold, if a user wants to use the Blender bindings and other third-party packages, e.g. those at PyPI? If Blender switches to Python 3.8, a user has to install these additional packages within Blender’s Python environment.

Even if you have Python 3.7 on your system and use Blender with Python 3.7, Blender still uses it’s internal Python. So if you install a library in your system’s Python, Blender cannot use it. You can delete Blender’s Python, so it will use your system’s one, or other methods: https://docs.blender.org/api/current/info_tips_and_tricks.html#bundled-python-extensions

Actually, there is a undocumented method, which is to enable pip in Blender’s Python itself:

  • Not sure if this method still works though, because I encountered that in Blender 2.81 ensurepip was removed?

Of course, if there is a frequently requested feature, it makes sense to upgrade the version.
However, the general policy should be that upgrades are well justified and not a result of simply depending on the most recent version just because it has the highest version number.

Blender’s community comes in a large variety and doesn’t have a single user type. What might be unimportant to one user, might be a life safer in another. If you come across such method, but say it’s only in 3.8, you have to wait till Blender upgrades, even if you request it. This staying up-to-date with technology is one of the reasons Blender is now popular, in comparison with Maya only now moving away from 2.7…

Edit: Nevermind, 2.81 comes with pip enables by default, so no need for ensurepip: https://developer.blender.org/T71856

Edit 2: You would install your library through pip in this way:

import subprocess
pybin = bpy.app.binary_path_python
subprocess.check_call([pybin, '-m', 'pip', 'install', 'your_library'])

Edit 3: Added pybin, '-m' , otherwise it can install the package in a Python environment which is not Blender’s one.

I can confirm this- at my studio my addons are deployed to users with varying Python experience so the ‘local version’ is all over the place. IE) there are technical artists using Houdini, Maya. More than a handful are still on 2.7. Rank and file artists sometimes don’t even have Python installed at all. For my addons, I spin up a local Flask server for documentation, so all I do is check to see if the module exists, if not- i use pip to install it (as demonstrated above). Works great in every strange environment I’ve tested it in.

1 Like

The code I posted about pip in Blender was not completely correct, please see the last update 2 post above.

Blender LTS 2.83.10 has just been released, however it is still using older versions of both Python and Numpy.

This LTS release is shipped with Python 3.7.4 (the latest security fix is 3.7.9). It also includes Numpy 1.17.0, while the latest is 1.17.4.

As these versions are within the CY2020 profile from the VFX Reference Platform, wouldn’t it be advisable to also update these (and perhaps other security fixes for major libraries) during the LTS releases?

Not nitpicking here, just doing a friendly reminder. Thanks!

Hi,

A good suggestion. The challenge is that no one is testing the builds except 1 or 2 developers. Bumping a version would mean that users will be the real testers when the new version is released. Of course this is far from ideal. We should at least have some test builds and active community testing in order to know for certain we don’t degrade in stability.

In case for snap packages we are free to have some beta builds, but that only covers linux… We should check with @JamesM if and when we could provide test builds on all platforms.

1 Like

Yes, plan is to push builds on edge, beta channels on Snap, and then candidate near the end of the milestone.

It is also possible to do this on Windows Store via test flights or even Chocolatey in the future.

We used test flight strategy on Windows Store for 2.83.10 LTS.

For MacOS we could look into brew, or via download page.
However, I do prefer using package managers for this.

1 Like

I cant open Blender 2.83 ver. 10 On my
MacOs 10.13 High Sierra is there a fix?