Specify the python interpreter at runtime

[vsiles]

Hi !

I'm writing a rust binary that uses pyo3 to compile python files, and inspect their bytecode. I have a strict restriction to use python3.8.
First of all, thank you for the nice work you did. Using pyo3 is really easy and nice ;)

Reading the doc of pyo3, I ended up creating a .cargo/config.toml file in my project to set PYO3_PYTHON to /usr/bin/python3.8. Builds, runs and tests are all working nicely. My understanding is that my rust binary will call a python binary at runtime, but it's not clear if it will just fetch information from it, or actually run code through it. Please correct me if I'm wrong.

Now, it happens that sometimes the binary is run with a PATH where python3 points to /usr/local/bin/python3.8 instead of /usr/bin/python3.8. Hopefully, they are the same binaries, so everything works great at the moment, but I'd like to prepare for the time they might diverge. Is there a way to explicitly tell my binary to use "that" interpreter, instead of relying on the PATH lookup ?

I found another question around specifying the libpythonXXX.so statically, so my understanding might be flowed. At the end of the day, I'm looking to statically specify which Python (exe or so) will be used by pyo3.

[adamreichold]

I am not sure if this is helpful, but the interpreter specified at build time via PYO3_PYTHON is used only to determine the Python configuration, e.g. linker flags, and its path is not used at runtime. Based on this, we should dynamically link libpython3.8.so if you specified a CPython 3.8 binary at build time. Linking against an absolute path like /usr/lib/libpython3.8.so to ensure that nothing else on the dynamic loader's search paths is picked up, would require that we selectively overwrite the linker flags determined by invoked the Python interpreter which does not seem very practical.

I think the easier way to achieve what you want would be to set LD_LIBRARY_PATH at runtime to point to the specific directory where the libpython3.8.so desired is to be found which should have a higher precedence than the other library search paths. Alternatively, you might want to try using patchelf and its --replace-needed or --set-soname commands to patch the library path to an absolute path after the fact.

[vsiles]

I see. Thank you for clarifying what happens at build time and at run time. I'll test the LD_LIBRARY_PATH approach, or just make sure the right runtime is first in the PATH.