failed to find 'bpy_types' module

[ocni-dtu]

Hey!

I just pip installed bpy on my machine, but when I try to import it I get the following error:

import bpy

AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead
ModuleNotFoundError: No module named 'bpy_types'
ModuleNotFoundError: No module named 'bpy_types'
ModuleNotFoundError: No module named 'bpy_types'
ModuleNotFoundError: No module named 'bpy_types'
ModuleNotFoundError: No module named 'bpy_types'
F0829 15:50:51.174837 3892 utilities.cc:322] Check failed: !IsGoogleLoggingInitialized() You called InitGoogleLogging() twice!
*** Check failure stack trace: ***
ERROR (bpy.rna): c:\users\tgubs.blenderpy\blender\source\blender\python\intern\bpy_rna.c:6662 pyrna_srna_ExternalType: failed to find 'bpy_types' module
ERROR (bpy.rna): c:\users\tgubs.blenderpy\blender\source\blender\python\intern\bpy_rna.c:6662 pyrna_srna_ExternalType: failed to find 'bpy_types' module
ERROR (bpy.rna): c:\users\tgubs.blenderpy\blender\source\blender\python\intern\bpy_rna.c:6662 pyrna_srna_ExternalType: failed to find 'bpy_types' module

[ocni-dtu]

It is version 1.2.3 of bpy and I'm on py36

[TylerGubala]

Ah, tricky. Could you verify for me that you did not install this into a Python virtual environment? I'm fairly certain I know what the issue is and will fix it this weekend.

[ocni-dtu]

No, unfortunately I'm doing exactly that. I'm trying to install it in a Conda environment.
It would be awesome if you can fix it during the weekend, but no pressure though. I can wait a few weeks if necessary.

[TylerGubala]

Honestly if you need it working right now you can simply go into your conda env, into the Scripts directory, cut the 2.79 folder out of there and paste it into the folder containing the Conda Python executable. The problem is that the version folder (2.79, currently) must be sibling to the Python executable. Since whatever environment you are in does not have the python.exe file located alongside the Scripts (pip, venv, etc) it is complaining since the path to bpy_types is supposed to be ./2.79/scripts/modules/bpy_types.py (relative to the current python.exe that is trying to import it) and it can't find it.

Windows is a known platform where these script files can be different, especially depending on your environment.

So in short:

1. Find the folder 2.79
2. Cut it from the current location
3. Paste it into the folder containing python.exe
4. Retry and paste your results

I'll have to think more on this issue and how it relates to setuptools and pip on Windows

Thanks for your patience.

[ocni-dtu]

Thanks man, the folder moving worked.
The proper pip installation is still needed though, for CI and I plan to have bpy as a dependency in the future. Take your time to come up with a good solution.
Cheers!

[TylerGubala]

Yes I will have to think of a good one. I'm thinking about different ideas... there might need to be a script or something that ensures that the version folder is in the correct location. That might bring the installation command up to two commands: one to pip install bpy (which may include an ensure_bpy script just for the purposes outlined in this issue), and one to actually run ensure_bpy.

I don't really like this solution though. I'll have to think about it for a while. If there was an intuitive way per setuptools to run an arbitrary command after installation (bdist_wheel OR sdist) then this would be a no-brainer. I'm not seeing a way to do that initially. I'll do more research.

That aside, I am glad that it is working for you currently. In the meantime it might be trivial to impliment such a script for CI (just after you pip install bpy, move the folder to the correct location) but yes, I will definately be looking into this so that you won't have to do that in the future.

[TylerGubala]

I'm separating out some of the functionality of this module.

The primary building steps will be performed with a project that I used previously, bpy-build. This will provide you with the wheel distributions that you need.

A secondary package, bpy-ensure, will install a console script and attempt to symlink the version folder for you. If the version folder cannot be symlinked (say you do not have sufficient permissions), then you will have to run the script manually with elevated permissions or create the link yourself.

The benefit of it being a symlink, is that I will not have to do anything with RECORD.TXT to reflect the changed location like I would if I physically moved the real folder; if the record was updated incorrectly, it would cause a whole lot of issues with pip, especially with uninstallation of the bpy package.

All of these changes are more or less waiting on this to be completed:

pypi/warehouse#4661

Once done, bpy will go back to being an sdist only package on pypi. The installation steps will look like the following:

1. pip install bpy
2. Bpy is an empty sdist package, move on to installing its dependencies
3. Since bpy-build is a dependency of bpy, install it
4. bpy-build fetches the correct prebuilt wheel for you
5. Since bpy-ensure is a dependency of bpy, install it
6. bpy-ensure is a sdist package with a custom install routine, during the custom install routine, it attempts to move the version folder for you
7. If the move fails, you have to run ensure_bpy, a command line script that comes with the bpy-ensure package.
8. bpy should now be set up for use.

Word of Caution

This is not supported officially by the Blender Foundation. In fact, many developers really do not like this project and have voiced their disdain, but I can never seem to get a straight answer from the Blender Foundation developers on whether they feel I should take this project down. See https://devtalk.blender.org/t/python-module-build-process-select-python-version/1852/7

I really am only doing this as a pet project and for my own side projects to depend upon (since I am maintaining this project it makes it pretty easy for me to fix both, since I know relatively what I'm doing).

That's not to say that I don't hold my code to high standards. If you submit a bug or have a feature suggestion I will make it my top priority to fix it or add it when I get the chance, however just note that this is not an official thing, and really is only maintained during my "free" time (I am not getting paid to do this). But the project could be squashed by Blender Foundation at any moment should they deem it necessary (I want to play nicely with everyone) and is subject to sweeping changes at any moment.

Hence "Development Status :: 3 - Alpha"

Hopefully that all makes sense. I'll report back when this is officially fixed.

Happy coding!

[ocni-dtu]

Thanks alot @TylerGubala ! It seems to work for now

[Leimun]

thank you.Move package is useful. But I tried to python bpy-build and bpy-ensure work,they couldn't be installed.

[TylerGubala]

Those packages are in progress. I need a good weekend to work on this. Thanks for your understanding

…

On Mon, Jul 1, 2019, 2:50 PM Leimun ***@***.***> wrote: thank you.Move package is useful. But I tried to python bpy-build and bpy-ensure work,they couldn't be installed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AFLEYR5ZUJUPG52SDFPMFZDP5JGY3A5CNFSM4FSGNJGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY7ARTY#issuecomment-507381967>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLEYR2TXTWIO6QD25AOWYDP5JGY3ANCNFSM4FSGNJGA> .

[kostasmarkakis]

Hi Tyler,
To begin with congrats for the great work you're doing,
Now i am having the same problem but mine is related to Pynstaller. I am using python 3.6.6 on Windows10 along with bpy1.2.4a0. The packaging of my program is succesfull but then you get the "'bpy_types' module" since as you said the python executable is not alogside 2.79.
The crude solution of copying 2.79 folder cant work for me as my program's executable created by Pynstaller using the --onefile option which uncompresses its contents to the temporary _MEIXXXX directory.
is there a workarround for this?
thanks and keep up the good work

[TylerGubala]

Wow, that's a very interesting use case. I know that at least for multiprocessing you have to enable the freeze safe portion of the code for pyinstaller. Maybe there is a smart way to replicate that. Thanks for the info.

…

On Wed, Nov 6, 2019, 7:37 AM Kostas Markakis ***@***.***> wrote: Hi Tyler, To begin with congrats for the great work you're doing, Now i am having the same problem but mine is related to Pynstaller. I am using python 3.6.6 on Windows10 along with bpy1.2.4a0. The packaging of my program is succesfull but then you get the "'bpy_types' module" since as you said the python executable is not alogside 2.79. The crude solution of copying 2.79 folder cant work for me as my program's executable created by Pynstaller uncompresses its contents to the temporary _MEIXXXX directory. is there a workarround for this? thanks and keep up the good work — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AFLEYR3DT3WAJ6FB5KXAAQTQSK3BXA5CNFSM4FSGNJGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDGMM4Q#issuecomment-550291058>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFLEYR66TPDRTRCMFEKYYG3QSK3BXANCNFSM4FSGNJGA> .

[TylerGubala]

@kostasmarkakis Actually I was wrong about it being similar to multiprocessing.freeze_support() it has nothing to do with that. It's much simpler and supported by PyInstaller. See #28 and the wiki.

If you have any other issue document it in a separate issue or if you continue having this one just comment in #28 with additional details and we can get it resolved.

Best of luck.

[tg90nor]

Just encountered this on a fresh install of python 3.6.8 on windows 10. Not using venv. Maybe there should be a note about copying the directory in the README?

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import bpy
Color management: using fallback mode for management
BLT_lang_init: 'locale' data path for translations not found, continuing
AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead
bpy: couldnt find 'scripts/modules', blender probably wont start.
Freestyle: couldn't find 'scripts/freestyle/modules', Freestyle won't work properly.
ModuleNotFoundError: No module named 'bpy_types'
ModuleNotFoundError: No module named 'bpy_types'
ERROR (bpy.rna): c:\users\tgubs\.blenderpy\blender\source\blender\python\intern\bpy_rna.c:6662 pyrna_srna_ExternalType: failed to find 'bpy_types' module
ModuleNotFoundError: No module named 'bpy_types'
ModuleNotFoundError: No module named 'bpy_types'
ERROR (bpy.rna): c:\users\tgubs\.blenderpy\blender\source\blender\python\intern\bpy_rna.c:6662 pyrna_srna_ExternalType: failed to find 'bpy_types' module
ModuleNotFoundError: No module named 'bpy_types'
ERROR (bpy.rna): c:\users\tgubs\.blenderpy\blender\source\blender\python\intern\bpy_rna.c:6662 pyrna_srna_ExternalType: failed to find 'bpy_types' module
F0221 18:48:29.669317 11880 utilities.cc:322] Check failed: !IsGoogleLoggingInitialized() You called InitGoogleLogging() twice!
*** Check failure stack trace: ***

[TylerGubala]

@tg90nor Added

[TylerGubala]

As part of the bpy installation, users are now expected to run "bpy_post_install", which will place the bpy addon scripts into the correct install location based on OS.

@ocni-dtu I know this issue has gotten long in the tooth, but by this point I actually have gotten a chance to buy a mac and linux machine where I have been able to test this functionality. It is available as an sdist right now on pypi test.

Would you mind weighing in your thoughts on if this is a solution that is easy to use for you?

Build from sdist

py -m pip install -U pip future-fstrings wheel
pip install -i https://test.pypi.org/simple/ bpy==2.82.post0 && bpy_post_install

[ocni-dtu]

Hi @TylerGubala
I haven't used bpy for some time, but running a post install script sounds a bit clunky.
Have you considered something like they talk about here: https://stackoverflow.com/questions/20288711/post-install-script-with-python-setuptools

[TylerGubala]

Unfortunately, based on what I am reading, that would mean everyone would have to build from sdist every time, which is a 2 hour long process, since the method you linked is incompatible with wheel by design.

Thanks for the link though.

[TylerGubala]

You should be able to pip install bpy && bpy_post_install on all platforms but linux now. This is the only way that I have found so far to get the installation properly set up with all the caveats and hardcoded file placements that Blender has. If anyone has a better recommendation that can be bundled in a wheel make me aware of it or submit a PR please.

(I have to figure out what the manylinux thing is all about.)

[mkeshavarzi]

Hey @TylerGubala, I'm working on Windows and used pip install bpy && bpy_post_install but am still having the same import "bpy_types" modules issue

I installed bpy through the .whl file in the Google Drive folder, and after running bpy_post_install I got:
"Configuration complete, enjoy using Blender as a Python module!" - so I believe I should be ok.

Am I missing anything else?

[Sality32]

i have same problem #13 (comment), i was use pip install bpy && bpy_post_install, but the result still same, what should i do ?

[tetsu]

I had the same issue on Google Colab, and this is how I fix. I hope this will be helpful to people who are working on AI with 3D models like I am.

!pip install future-fstrings bpy==2.91a0 && bpy_post_install
!cp -r /usr/lib/python3.7/site-packages/2.91 /usr/local/lib/python3.7/dist-packages

[ziwenjie]

Honestly if you need it working right now you can simply go into your conda env, into the Scripts directory, cut the 2.79 folder out of there and paste it into the folder containing the Conda Python executable. The problem is that the version folder (2.79, currently) must be sibling to the Python executable. Since whatever environment you are in does not have the python.exe file located alongside the Scripts (pip, venv, etc) it is complaining since the path to bpy_types is supposed to be ./2.79/scripts/modules/bpy_types.py (relative to the current python.exe that is trying to import it) and it can't find it.

Windows is a known platform where these script files can be different, especially depending on your environment.

So in short:

1. Find the folder 2.79
2. Cut it from the current location
3. Paste it into the folder containing python.exe
4. Retry and paste your results

I'll have to think more on this issue and how it relates to setuptools and pip on Windows

Thanks for your patience.

Hi:
I have the same problem in ubuntu, and I can't solve it in this way.

[aprath1]

For anyone else facing trouble with importing bpy after shifting '2.79' folder to the location of python.exe, in case you are using a virtual environment say for example with 'poetry' or so:
Pasting the 2.79 folder into the python.exe of the source python ( => the source Python.exe from which the virtual environment was created, not the one in your virtual environment) resolved the issue. But this is actually weird as the virtual environment
purpose is not satisfied here i.e, isolating project-based dependencies from source python. Wonder if blenderpy doesn't consider virtual environment? Unfortunately has to do other priority stuff so can't look into blenderpy codes for this at the moment...

Anyone finding a standardized solution please comment below.

[hzy-del]

pip install bpy==2.91a0 && bpy_post_install

you can try this for ubuntu!!