> Hello,
>
> Konrad Hinsen <konrad.hin...@fastmail.net> skribis:
>
>> Konrad Hinsen <konrad.hin...@fastmail.net> 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
