"Rutherther" writes: >> Hello, >> >> Konrad Hinsen skribis: >> >>> Konrad Hinsen writes: >>> >>>> I have changed my mind. In the sys.path outputs shown, there are no >>>> paths from add-on packages. It's just the Python standard library. >>>> Maybe our sitecustomize.py is not run at all, but if it is, it didn't do >>>> anything to sys.path. There must be a bug somewhere else. >>> >>> Our sitecustomize.py is indeed not run at all, so this definitely is a >>> different problem. >>> >>> Evidence: Run Rutherther's example, adding the -v option. The long >>> output is attached, both for "./profile/bin/python3 -v" and "$(realpath >>> ./profile/bin/python3) -v". Search for "site-packages" to find the >>> interesting parts. If you don't use realpath, large parts of the >>> initialization are not done. >>> >>> There are lots of ../../ in the path shown in these log files. If Python >>> resolves them lexically, as the normpath function does, that would >>> probably explain most of these issues. > > I am not sure I understand this right. I am looking at the output, and > it has `/tmp/b/profile/bin/../../hash-python-3.10.7R/{rest}`, omitting > the gnu/store even here. Why is it significant how these paths are > evaluated, if there is the gnu/store part missing already? > > Regards, > Rutherther 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,