Skip to content
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

Python's sys.executable points to Julia's binary on Windows #958

Open
pedromxavier opened this issue Jan 20, 2022 · 6 comments
Open

Python's sys.executable points to Julia's binary on Windows #958

pedromxavier opened this issue Jan 20, 2022 · 6 comments

Comments

@pedromxavier
Copy link

When Python's sys module is loaded via pyimport("sys") its executable returns Julia's path instead of Python's. The same doesn't happen on Linux.

To reproduce this issue (Windows 10, Julia 1.7.0, PyCall 1.93.0):

julia> using PyCall

julia> sys = pyimport("sys")
PyObject <module 'sys' (built-in)>

julia> sys.executable
"C:\\Users\\User\\AppData\\Local\\Programs\\Julia-1.7.0\\bin\\julia.exe"
@stevengj
Copy link
Member

Isn't that correct? We are not running python.exe.

@stevengj
Copy link
Member

stevengj commented Jan 20, 2022

Oh, I see, the definition of sys.executable in the Python docs is

A string giving the absolute path of the executable binary for the Python interpreter, on systems where this makes sense. If Python is unable to retrieve the real path to its executable, sys.executable will be an empty string or None.

(emphasis added)

See also these discussions about sys.executable for embedded python:

It seems like this happens a lot for programs embedding Python. In our case, PyCall.python is the path of the Python interpreter corresponding to the libpython we are linking to, so we should be able to set sys.executable to this.

@pedromxavier
Copy link
Author

pedromxavier commented Jan 20, 2022

Very interesting definitions. On Linux the behavior is the following:

julia> using PyCall

julia> sys = pyimport("sys")
PyObject <module 'sys' (built-in)>

julia> sys.executable
"/usr/bin/python3"

as ,IMO, was expected. Apparently, there is no clear correspondence between PyCall.python and pyimport("sys").executable. This brings some inconsistency across platforms, getting even more unpredictable outcomes when PyCall.conda == true, which is the main point of #958.

@stevengj
Copy link
Member

stevengj commented Jan 21, 2022

It looks like sys.executable is set from the configuration, and apparently we can use this API to change it when we initialize Python by using Py_InitializeFromConfig.

@nicolaefilat
Copy link

Is there a fix for this issue? I have to use a python library that makes use somewhere of sys.executable and because I am on windows that points to julia and the code crashes.
My current workaround was to modify the library code directly to point to the conda's python

@stevengj
Copy link
Member

Ideally, someone has to figure out the PyConfig API and make a patch to set this correctly.

In the meantime, one could simply do:

pyimport("sys").executable = PyCall.python

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants