Fix getProgramPath() to find Python module in virtual environment on Windows and Linux - #368
Fix getProgramPath() to find Python module in virtual environment on Windows and Linux#368lukashof wants to merge 3 commits into
getProgramPath() to find Python module in virtual environment on Windows and Linux#368Conversation
7dd9050 to
577521a
Compare
577521a to
17924a6
Compare
17924a6 to
8e8a060
Compare
|
I was never happy with the solution I proposed. I just rebased it to the latest version. In doing so, I found that I couldn't compile via the setup.py anymore because pybind wouldn't find my Python installation in a non-standard directory on Windows. I've added a commit to address this. I've also reworked the original solution to the program not finding the module correctly. It now identifies whether it runs in Python from a mismatch between the executable and module. The correct directory is also found by looking for the data and resources folders. So far, I only tested the Windows version with venv. I'll test on Linux too. Unfortunately, I don't have access to a Mac. I can only trust my LLM of choice for that bit. |
|
I tested my changes today with Anaconda and Linux. So it works for me in these configurations:
Feel free to let me know whether you need any additional info / tests or if this is even something you are interested in at all. |
8e8a060 to
45a79e9
Compare
There are various instances where data like scene or geometry files is loaded and
getProgramPath()is used to find the right folder. However, when using the Python bindings from a virtual environment using the built-in venv-Module this won't work, since the method returns the path to the global Python interpreter. The only (very crude) workaround I have previously found was to place the relevant data in the global interpreter, which is not ideal and requires admin-privileges.This PR contains a modification to find the correct Path of the venv, if the python bindings are used. I realize the implementation is a bit simplistic and depends on the found executable's name, and might therefore not cover all available Python distributions.
I made no changes to the Apple implementation, since I don't have a machine available to test this on.
I have previously discussed this with @digitalillusions in #283, where he mentioned that the issue does not occur with Anaconda. I tested my solution with Anaconda on Windows as well and had no issues.
This might solve the problems from discussion #151 and #254, although the latter one was already closed.
Looking forward to any feedback!