os.execl fails to execute Python

[alexyao2015]

From a python script, attempting to run os.execl with Python as the executable fails because Python seems to locate /install as its path instead of the real path. This installation was installed using uv, but I'm still experiencing this issue.

In the real world, this affects the yocto poky project which works fine with other Python distributions but fails to run with this one.

Example:

import sys
import os

os.execl(sys.executable, "test")

Output:

$ python test.py
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'test'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = '/install/lib/python3.11'
  sys._base_executable = '/usr/bin/test'
  sys.base_prefix = '/install'
  sys.base_exec_prefix = '/install'
  sys.platlibdir = 'lib'
  sys.executable = '/usr/bin/test'
  sys.prefix = '/install'
  sys.exec_prefix = '/install'
  sys.path = [
    '/install/lib/python311.zip',
    '/install/lib/python3.11',
    '/install/lib/python3.11/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007f997d316740 (most recent call first):
  <no Python frame>

Using another python distribution (e.g. from Ubuntu or PyEnv) that has the correct compiled in paths:

$ python test.py 
Python 3.11.9 (main, Jan  8 2025, 12:47:30) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

[zanieb]

I can't reproduce.

uvx --managed-python python -c 'import sys; import os; os.execl(sys.executable, "test")'

Does this occur after uv python install 3.11 --reinstall? Are you on the latest uv version?

[alexyao2015]

Here's a couple of examples to reproduce the issue. Oddly enough, I've found that running uv python install 3.11 will "fix" the issue and prevent it from occurring only with the uv debian image. In the standard debian image, this is not the case. You can try both examples using the command below.

ARG EXAMPLE=1

FROM ghcr.io/astral-sh/uv:0.8.3-debian@sha256:1b6daf4fe4966925d830a275ec5aa5ccf2b40cc1ddc96b5a3b69ae8e17144e10 AS base1

# Using 3.11 allows the build to succeed, any other version fails
# We don't even need to add the python installed to the path
# RUN uv python install --default --preview 3.11
#
# OR
#
# RUN uv python install 3.11

# This alone without a version also fails
RUN uv python install

FROM debian:bookworm AS base2
COPY --from=base1 /usr/local/bin/uv /usr/local/bin/uvx /bin/

# Installation like this also results in the same error
# COPY --from=ghcr.io/astral-sh/uv:0.8.3 /uv /uvx /bin/

# Doesn't matter what we do here. It always fails
RUN uv python install 3.11

###
# Test example case
###
ARG EXAMPLE
FROM "base${EXAMPLE}"

RUN uvx --managed-python python -c 'import sys; import os; os.execl(sys.executable, "test")'

docker build --no-cache --build-arg EXAMPLE=1 .
docker build --no-cache --build-arg EXAMPLE=2 .

[alexyao2015]

Seems like it works with Python 3.11 only on the debian uv image because this image comes with Python 3.11. My guess is having a working python distribution with the correct compiled in path enables the uv python to find the correct paths. I think the only solution for this is to correct the embedded paths to the actual path of the installation.

[zanieb]

We do correct the embedded paths, in general. Maybe we're missing some? I'm not sure what makes execl unique in this regard.

[alexyao2015]

Seems like it. os.execl used in the manner of the example causes argv0 to be overwritten to something else other than where the binary is located. Seems that Python first attempts to locate the prefix using the path of the executable using argv0, then the current directory, and finally the compiled in path. The docs are missing the last point of using the compiled in path.

In this case, we killed the argv0 by using os.execl, which can also be emulated through exec -a in bash with the following examples.

PYTHON=$(readlink ~/.local/bin/python) \
    && bash -c "cd $(dirname ${PYTHON}) && exec -a wrong_name ${PYTHON}"

PYTHON=$(readlink ~/.local/bin/python) \
    && bash -c "exec -a wrong_name ${PYTHON}"

In the first example, Python is able to run normally because it can locate the prefix using the current directory. In the second example, this also doesn't work and thus causes the same error as shown before.

The usage of os.execl in this manner is improper in the noted project (which was since resolved in newer versions), but the presence of this issue confirms that some compiled in paths aren't being fixed.

[geofft]

Ah, yes, I've noticed this code before in CPython and thought it was strange - with your example I think I can now argue that it's a bug. :) Most platforms have better ways for a binary to detect its own path than using argv[0], e.g. /proc/self/exe, and CPython should use them if possible.

In your case, I believe you can work around this by activating the venv. The discovery logic does also search $PATH for a directory containing argv[0] (which appears to be undocumented, too). In the case of Poky, they are doing os.execl(sys.executable, "bitbake-server", ...). So, assuming that bin/bitbake-server exists in your venv, then adding that directory to PATH should make the discovery logic work. (I also expect another worrkaround is to patch the code to do something like os.execl(sys.executable, os.path.join(os.path.dirname(sys.executable), "bitbake-server"), ...) instead.)

But let me take a look at whether we can improve CPython's logic here, ideally in a way we can get fixed in CPython itself.

---

As a fun side note, here's what's going on with the results you're seeing in Docker:

First - you're using test as the second argument to os.execl, so the discovery logic in Python is looking for a command named test on $PATH. It turns out there is a /usr/bin/test! Python then uses that full path it finds to find a standard library in a relative directory, in this case, /usr/lib/python3.11 and /usr/lib/python3.11/site-packages. If those exist it will use those.

Even if you gave a nonexistent command name, the Docker default cwd is /, and Python will go look for lib/python3.11 and lib/python3.11/site-packages in the current directory. Because /lib is a symlink to /usr/lib, it will again successfully find the system Python's standard library. So, re:

Seems like it works with Python 3.11 only on the debian uv image because this image comes with Python 3.11. My guess is having a working python distribution with the correct compiled in path enables the uv python to find the correct paths.

It's actually way scarier - having a Python distribution of the same version installed enables uv python to find the wrong standard library. Fortunately there aren't too many differences between the standard library in each copy, and also most of our compiled modules are built into the binary, not separate loadable modules, so in practice this is likely to appear to work, most of the time. But this is a real motivator to patch this logic and ensure we never load the wrong Python's standard library!

Finally, when you run uv python install 3.11, that changes the default for uvx --managed-python to be 3.11. Without it, the default is (currently) 3.13. That's why there's a change of behavior even without ~/.local/bin being on your PATH: this image has a /usr/lib/python3.11 but not a /usr/lib/python3.13.

(Even if it were on your PATH, it would only make a difference if the argv[0] you're passing to os.execl is in that directory. uvx does activate the temporary venv it creates, so, uvx --managed-python python -c 'import sys; import os; os.execl(sys.executable, "python")' would work properly, as would "python3" and "python3.13", since they are all found in the venv's bin directory. But "test" would not.)