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

Previous Next

Full log

Message #32 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 11:59:45 +0000

[Message part 1 (text/plain, inline)]

"Rutherther" <rutherther <at> protonmail.com> writes:

>> 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

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,

[run-in-namespace.patch (text/x-patch, attachment)]

Previous Next

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