Fix getProgramPath() to find Python module in virtual environment on Windows and Linux
#368
+50
−5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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!