Hi, Rutherther <ruthert...@protonmail.com> writes:
[...] > Okay, I spent a bit of time on this, and I think I get it now. > This seems to boil down to something in Python wrongly handling > the argv0, where it looks at the path, being /tmp/a/profile/bin/python3, > substitutes the symlink > /tmp/a/profile/bin/python3/../../hash-python-3.10.7/bin/python3, and then > probably calls something like normpath on it, and it becomes > /tmp/a/hash-python-3.10.7. Whereas the correct approach is to first get > the actual path /tmp/a/profile/bin/python3 is at, being > /tmp/a/gnu/store/hash-python-3.10.7R/bin/python3, and unwrap the symlink > from there. This happens even if python3 is called from PATH, I suppose > Python then looks through PATH and again finds the python3 file outside > of the store. > > As a workaround, The workaround looks smart (too smart for my tired brain tonight), but to be honest I'd rather have Python handle the relative paths correctly, or work around it in our sitecustomize.py script that runs early when Python runs. I doubt submitting a patch fixing this in Python will be accepted, for backward compatibility reasons (I think Josselin had done so already). Looking back for it, I've seen reports of the issue going back to 2008 [0], and a more recent one in 2021 [1]: [0] https://github.com/python/cpython/issues/46542 [1] https://github.com/python/cpython/issues/88482 It seems using realpath wouldperhaps do the right thing instead of using normpath? It resolves symlinks, appears to conform to POSIX. See some sample output from [2]. [2] https://stackoverflow.com/a/40311142/2896799 -- Thanks, Maxim
