Open pedromxavier opened 2 years ago
Isn't that correct? We are not running python.exe
.
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 orNone
.
(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.
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.
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
.
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
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
When Python's
sys
module is loaded viapyimport("sys")
itsexecutable
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):