First time poster here: I am the “maintainer” of a module called ‘bpy’ on pypi. It allows prospective addon developers to install the Blender as a Python module into their venv for unit testing, or for the purposes of making a 3d enabled application using Blender as the driver for the Graphics.
Currently, however, I am facing a problem. I use an automated build process that follows very similarly to the @Ideasman42 topic on the Blender official wiki “Building Blender as a Python module” (credit to the original author, although my bookmark to this page has been broken since the wiki’s migration…)
The problem is that, after building Blender as the Python module
bpy, which I am doing for multiple Python versions (maybe there is my issue, maybe that just won’t work…?), the bpy module is looking for the incorrect
pythonXX.dll; it always seems to be looking for
My distribution process is like this:
- I enter my venv:
call activate venv
- then build:
python setup.py bdist_wheel
- exit the venv:
- Repeat steps 1 through 3 for each version of Python I have a venv for 
- Finally, upload:
twine upload dist/*
 This retrieves the git sources, svn libs if the platform is Windows, and performs the build action using cmake
 My optimistic goal is support for all (32-bit or 64-bit) Python versions 3.4 or greater; I currently only support Windows
My thought is, that by entering into the Python virtual environment prior to configuring and building, cmake would recognize the current version of Python (I think
activate sets the
PYTHON_PATH variable locally…?) and therefore would build to the correct version of Python.
However, that seems to not be the case, as on
import bpy I immediately get an
ImportError: DLL load failed: The specified module could not be found
Attempting to trace this import error down, I made a temporary copy of the current
pythonXX.dll , and renamed it to
python36.dll on a hunch. Lo and behold, just as I thought, it is trying to reach out to
python36.dll! (Or at least, that’s how I’m understanding this?)
 I believe I was in my newly created Python 3.7 Virtual environment at the time
(3.7-32) copy venv\3.7-32\Scripts\python37.dll venv\3.7-32\Scripts\python36.dll
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:06:47) [MSC v.1914 32 bit (Intel)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.
>>> import bpy
ImportError: Module use of python36.dll conflicts with this version of Python
(3.7-32) del venv\3.7-32\Scripts\python36.dll
What the above error is telling me, and the fact that it is a different error than before the copy rename operation took place, is that when I
import bpy, regardless of the system settings of Python that were present at cmake’s Configure/Build time, bpy will still attempt to latch onto Python 3.6’s dll.
This is rather unfortunate in my opinion. First, there are some proprietary, prebuilt
so Python packages out there that could potentially work very well in combination with the Blender as a Python module
fbx Python sdk comes to mind, and only works on Python 3.3. So the choice in Python version can sometimes be a motivating factor due to surrounding factors.
Secondly, as new Python versions come out (3.7 is a recent addition), it can be useful for Blender addon maintainers to unit test their addons with the new Python runtimes and potentially address issues ahead of time, or test out new language features and possible performance upgrades introduced in the latest major release.
With a flexible build process, that could create the
bpy Python module for any version of Python, using proprietary Python modules or integrating unit tests for a Blender addon would be a snap. It could even potentially be part of continuous integration.
In my opinion this is a huge missed opportunity. But I am only a guy on the internet, and this is just my opinion.
But I want to do better than that; I would like to remedy this myself, or help remedy this for others so that they can start using the
bpy Python module in their projects, regardless of what their Python version of choice is (within reason).
That being said, I have my own hypothesis on what the potential causes could be. For starters, I find it very odd that, when we have to download the svn libs for Windows, it comes with the relevant Python
.lib files, and during the configuration process, I can’t seem to find the cmake entry for
Shouldn’t we be able to override which
.lib files are included into the C build process?
Regardless, I would like to be able to help remedy this issue at the very least. If this is something on the side of the C/C++ API, while I’m not extremely familiar with C/C++, I’m at least comfortable enough to perform my own builds, do my own tests, and Debug code. The main point is, I would like to not just fix this, but fix it "The Right Way"™, and am ready and willing to provide help and information.
Thank you so much for all of your time reading this. If this simply isn’t feasible, that’s fine, I just can’t think of a reason why it wouldn’t be at the moment.
Here is my repository:
And my initial Blender Stack Exchange post regarding this (my be removed as off-topic in the near future)
Blender as Python module; link to the correct pythonXX.dll?
Thanks in advance!