-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't resolve Python executable path for subprocess calls #23
Comments
Thanks for raising this issue! May I ask which function is invoking the Python executable? The main one that comes to mind is when msdsl is used to generate models. In that case, the current workaround is to set the environment variable Relevant code: Lines 42 to 51 in acec424
|
I encountered it when running |
OK, thanks for letting me know. I'll move the issue to msdsl. |
When resolving the path of the Python executable for a subprocess call, the
sys.prefix
can be different from the one that would be used when not resolving it. Python Virtual Environments work by relying on the module search paths being determined by thesys.prefix
. Thus in the default case, in which the Python executable of the virtual environment is just a symbolic link to the system's executable, the resolving of the path will cause the wrong environment to be used (aka one in which anasymod might not even be installed).Thus it would be nice if either Python executables could be special-cased for this, or the call to
get_full_path
(used also from within thewhich
function insidefiles.py
) can be omitted in respective use-cases.The text was updated successfully, but these errors were encountered: