You are not logged in.
Hallo,
i need Python 3.7.9 for Arch repos Blender (3.7 is the only officially supported version) as 3.9.1 is problematic (deprecated/missing API) so i installed pyenv.
$ pyenv global 3.7.9
$ python -V
3.7.9
But Blender still picks up 3.9.1:
$ blender --python-console
Read prefs: /home/user/.config/blender/2.91/config/userpref.blend
Python 3.9.1 (default, Dec 13 2020, 11:55:53)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>
Any idea how to run Blender with Python 3.7?
Last edited by Maniaxx (2020-12-24 14:27:43)
sys2064
Offline
The official in repo python version is 3.9
By changing your global env to 3.7.9 you are doing what amounts to a partial upgrade and you seem to have an XY problem.
Do you actually have an issue with blender using 3.9 or are you trying to mangle your environment into a frankenstein monster because another software you are using (... potentially out of repo) uses python 3.7 ? Why are you not just changing your pyenv for that one software if that is the case and if you really actually need blender to use 3.7 instead you will need to manually rebuild it against the older dependency including all of the relevant dependants (... and so fort).
See the ABS for how to acquire PKGBUILDs of repo packages so you can rebuild it relevantly, though at this point I'd say it'd be easier if you setup a local copy of blender (... potentially using the official prebuilt packages)
Offline
The official in repo python version is 3.9
Blender nevertheless has 3.7.
https://svn.blender.org/svnroot/bf-blen … ython/lib/
By changing your global env to 3.7.9 you are doing what amounts to a partial upgrade and you seem to have an XY problem.
I'm not changing anything.
https://wiki.archlinux.org/index.php/python#Python_3
Do you actually have an issue with blender using 3.9
As already said 3.9.1 has removed api functions like 'getchildren' breaking addons like openbim or pyclone.
you can rebuild
No need. Blender officially provides pre-compiled (and pre-bundled with python37) releases. That's not the point. It's about fixing the Arch release.
Last edited by Maniaxx (2020-12-24 10:30:43)
sys2064
Offline
The Arch package is built against 3.9 it doesn't matter what it ships with upstream. If you want to use 3.7 with the arch package you need to rebuild it. You can also open bug reports so compat with 3.9 for failing plugins can be fixed, like has happened e.g. in https://github.com/archlinux/svntogit-c … 5eb9b7203a
And as rebuilding takes a long time and enforcing 3.7 on a global scale can have other ramifications I'm suggesting it might be more profitable to use a prebuilt blender release in your particular instance. But even if you wanted to use the Arch package you'd still need to rebuild it locally as right now all python internals of Blender that ARE compatible with 3.9 use 3.9
Last edited by V1del (2020-12-24 11:19:42)
Offline
That's completely wrong. Blender is not compiled against Python, its compiled with Python. There is no linking or symbol dependency involved. They are using completely independent high level communication. That doesn't matter anyway.
Its common practice to use/downgrade Python versions with virtual environments. It's officially encouraged to do so as well as Blender is known to have issues with system-env Python. That's why they provide options to do so. The question is how. Its not very well documented. I do not want to exclude any recompilation per se though.
I'm not reinventing the wheel here. It's about speeding things up. Blender has env vars for external Python for example. I will try these next. I just hoped for someone who already done this.
Last edited by Maniaxx (2020-12-24 14:21:53)
sys2064
Offline
That's completely wrong.
That's completely rude. And incorrect. Everything you were told was correct. Perhaps incomplete in the sense that there is another way around, but that's not nearly the same as being "wrong". Blender uses the version of python it was configured to use when it was built. Rebuilding it would be the way around this. There is another way - a method to get blender to NOT use the version of python configured during it's build, but rather the one specified by the system environment (in turn set by pyenv). But you need to tell blender to do this. If only there were some page, or some manual, or some such mysterious thing that covered options that could be provided to a program on start up to tell it how to behave ...
Blender has some env vars for external Python. I will try these next. I just hoped for someone who already done this.
You hoped someone else would have read the man page so you wouldn't have to. I have, and the answer is very easy to find there? So this is pure help vampirism?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Solved. I found what i was looking for. Thanks anyway.
sys2064
Offline
Maniaxx can you tell us how you solved it? I am interested, too.
Maniaxx wrote:That's completely wrong.
That's completely rude.
I do not understand. Rude is using rude words, but this person has not done this. If this is your definiton of rude you have been rude too?
Maniaxx wrote:Blender has some env vars for external Python. I will try these next. I just hoped for someone who already done this.
You hoped someone else would have read the man page so you wouldn't have to. I have, and the answer is very easy to find there? So this is pure help vampirism?
What is "pure help vampirism"?
Maniaxx, it is good to read man pages.
A dog is a man's best friend.
Offline
V1del wrote:Do you actually have an issue with blender using 3.9
As already said 3.9.1 has removed api functions like 'getchildren' breaking addons like openbim or pyclone.
I'll note this was deprecated in python 2.7 and 3.2, meaning they had 10 years to fix it and there was never a python 3.x release viable for general use in which it *wasn't* deprecated.
And addons might be broken, but is blender itself broken?
...
Did you consider submitting bug reports for addons which are broken, in order to fix them so they work on python 3.9? This is a pretty easy fix... then you could avoid faffing around with old python versions.
Last edited by eschwartz (2020-12-27 03:44:54)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Yes, all correct. V1del was right in the first place, i was wrong. Its too hardwired to get replaced. Its probably less the linking but more the Python backend itself (runtime version difference).
Regarding the deprecated API the official prebuilt Blender version does work as a workaround for now. The addon author has been contacted, a bug report placed.
Regarding OpenBIM, its not a Python problem. The author knows about the bug but cannot reproduce it himself.
Sorry for the rude words.
sys2064
Offline
I'm pretty confused. You said openbim is broken due to using getchildren. It seems to be this right here: https://github.com/IfcOpenShell/IfcOpen … etchildren
lo and behold -- use of getchildren. No issue has been filed for it in this github repo. It's very reproducible to look up the docs at https://docs.python.org/3.8/library/xml … etchildren
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I'm pretty confused. You said openbim is broken due to using getchildren.
Actually its not clear what causes the bug. The stack trace itself doesn't contain getchildren but its in the source code. These probably are different issues.
sys2064
Offline