Edit.. If having encodings
hassles try virtualenv
After installing python 3.77 to /usr/local/
from a tarball, thought I would create a new python venv for blender. Using /usr/local/bin/python3.7 -m venv foo --copies
I ran into the no module named encodings error, and found no way to alleviate the situation.
Thought I'd give the somewhat deprecated virtualenv
a try, and bingo, blender ran straight up.
/usr/bin/virtualenv -p /usr/local/bin/python3.7 --always-copy foo
creating a copy of the python to venv and from it blender runs without any extra steps required.
A way for Ubuntu
Having horrible issues building blender currently, so have gone thru the motions of setting up virtual environments for freshly downloaded 2.91.2 and 2.92.0
Have both in vers folder
Note commands shown below are <prompt> $ <command>
shitbox:~/blender/vers$ ls
blender-2.91.2-linux64 blender-2.92.0rc-linux64
renamed the python folder in both from python to _python
shitbox:~/blender/vers/blender-2.92.0rc-linux64/2.92$ mv python _python
Now set up a virtual environment named "bar" and changed into that directory
shitbox:~/blender$ ~/blender/vers/blender-2.92.0rc-linux64/2.92/_python/bin/python3.7m -m venv bar --copies
shitbox:~/blender$ cd bar
next have made link copies of blender's distribution python lib to venv lib
shitbox:~/blender/bar$ cp -as /home/batfinger/blender/vers/blender-2.92.0rc-linux64/2.92/_python/lib .
Created symlink to blender into the venv's bin.
shitbox:~/blender/bar$ ln -s /home/batfinger/blender/vers/blender-2.92.0rc-linux64/blender bin/blender
activate the venv
shitbox:~/blender/bar$ source bin/activate
and start blender telling it to use this venv
shitbox:~/blender/bar$ BLENDER_SYSTEM_PYTHON="$VIRTUAL_ENV" blender
The environment variable can be set in the activate script in your venv's bin folder, however on Ubuntu I am using direnv
which automagically activates the environment when entering the folder using an .envrc
file. So I have stuck it in there
export EDITOR=nvim
source $(pwd)/bin/activate
export BLENDER_SYSTEM_PYTHON="$VIRTUAL_ENV"
echo "Blender 2.92"
and similarly for 2.91 in "foo"
(foo) shitbox:~/blender/foo$ blender
Read prefs: /home/batfinger/.config/blender/2.91/config/userpref.blend
found bundled python: /home/batfinger/blender/foo
Can install in the venv with pip
pip install matplotlib
and bingo in blender
>>> import sys
>>> sys.executable
'/home/batfinger/blender/foo/bin/python3.7m'
>>> import matplotlib
>>> matplotlib
<module 'matplotlib' from '/home/batfinger/blender/foo/lib/python3.7/site-packages/matplotlib/__init__.py'>
Notes.
Above is demonstrating how to use the python that ships with blender to make a venv. Would be very inclined to download and build the matching version Python3.7.7 and use this as the basis for a venv. (It's my experience that python builds pretty well hassle free)
It's been a while since I downloaded an official build of blender and was a little surprised to see both versions above using python 3.7.7. (Have been building against 3.8.2 since blender 2.7, last run of install_deps.sh
to build was using 3.9.1 .. miss not building with the "latest" .. don't miss when it doesn't work)
Since both venvs use same python version it feels a little overkill to install scipy, matplotlib, pynvim, plumbum
and other 3rd party modules I use alot for each venv.
In the past any module I wish to have available for all instances I have used
pip install pynvim --user
which is unavailable in venvs as setup above, unless python --system-site-packages
was used creating venv, or in hindsight edit pyvenv.cfg
to have include-system-site-packages = true
or add a path to python path in .envrc
with
export PYTHONPATH="$HOME/.local/lib/python3.7/site-packages"
will make that path available to python in your venv, but not in blender..
A quick way around this is make a script to add paths to blender
addpaths.py
import sys
sys.path.append("/home/batfinger/.local/lib/python3.7/site-packages")
and start blender with
blender -P addpaths.py
TODO write a script to automate the above.
_python
is a more reversible option. (It can then be used as version to create venv.I $\endgroup$