GNU bug report logs - #73304
Python in relocatable guix pack leads to wrong sys.path

Previous Next

Full log

Message #29 received at 73304 <at> debbugs.gnu.org (full text, mbox):

From: Rutherther <rutherther <at> protonmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>,
 Konrad Hinsen <konrad.hinsen <at> fastmail.net>
Cc: 73304 <at> debbugs.gnu.org, Josselin Poiret <dev <at> jpoiret.xyz>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#73304: Python in relocatable guix pack leads to wrong sys.path
Date: Fri, 31 Jan 2025 10:10:51 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.