trouble getting python binding in windows 10 with vcpkg build #3461
-
hi Installation using this: i can see the OpenImageIO.cp310-win_amd64.pyd in my user folder I have set this in my PYTHONPATH env variable too. so now if i start my conda env. using this python
if i do what do i need to make OpenImageIO python binding avail for me on windows? thanks |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
I'm not a python on Windows expert, so I'm hoping somebody else can also chime in. As far as not finding the module, my first guess would be to make sure your PYTHONPATH environment variable contains the directory where the module ends up getting installed? |
Beta Was this translation helpful? Give feedback.
-
I can speak to this issue as I was having similar problems in the last year due to moving to python 3.8 (and recently 10). In Python 3.8, they changed how DLL resolution can safely be handled on Windows. I recommend reviewing this post which poses the generic problem of DLL loading and the one answer cites the Python 3.8 What’s New Docs as well as an example of setting it using the os.add_dll_directory() function. Basically modifying the PATH env var will no longer work in 3.8+ for DLL resolution (It of course still works in 3.7 and older). https://stackoverflow.com/questions/214852/python-module-dlls Another thing I’ve done in my VCPKG build testing is that the PYD and DLLs are in separate build folders. If you build the CMake way, they are in the same directories so I’ve determined that VCPKG is being overly clean about how it’s builds are created and thus I can copy the PYD into the same directory of the DLLs (or better yet, extract the contents to a clean directory away from re-building folders). As to specific Python version builds against VCPKG, this is a little tricky. They recently added a ‘versions’ mechanism for allowing a user to essentially provide config rules as to what to use, but I’ve found it to be not always reliable as any dependencies that also require Python will have to have had snapshots of those python versions to source from (PyBind11, for example, I’ve not been able to build via VCPKG with python 3.7 due to a snapshot issue and thus overall I would be wary building OIIO with 3.7 via VCPKG). Personally, I recommend building with CMake OIIO with the python you absolutely need and worse case using VCPKG to get non-python dependent libraries to point to in your CMake. It gives the most flexibility in choosing your specific needs, but agree it is not the easiest to do. I can confirm I have built for Python 3.8, 3.9 and 3.10 this way before they were supported by default VCPKG builds. Hope this helps! |
Beta Was this translation helpful? Give feedback.
I can speak to this issue as I was having similar problems in the last year due to moving to python 3.8 (and recently 10). In Python 3.8, they changed how DLL resolution can safely be handled on Windows. I recommend reviewing this post which poses the generic problem of DLL loading and the one answer cites the Python 3.8 What’s New Docs as well as an example of setting it using the os.add_dll_directory() function. Basically modifying the PATH env var will no longer work in 3.8+ for DLL resolution (It of course still works in 3.7 and older).
https://stackoverflow.com/questions/214852/python-module-dlls
Another thing I’ve done in my VCPKG build testing is that the PYD and DLLs are in separa…