Re: Guix's python has pip's user dir in its loadpath

[John Kehayias]

Hi,

On Sat, Jul 01, 2023 at 11:57 AM, Maxim Cournoyer wrote:

> Hi,
>
> Wojtek Kosior <koszko@koszko.org> writes:
>
>> The precedence of local, pip-installed Python libraries over Guix ones
>> has already been a source of bugs. And these can be hard to diagnose.
>
>> I imagine an optimal solution would be to configure this behavior on
>> per-package basis. The vast majority of applications does not need to
>> load local libraries. There are just a few exceptions like
>> `python-virtualenv`.
>>
>> Once I did write a package definition that deliberately disabled user
>> site dir package loading. I used code similar to what's below.
>>
>>> (modify-phases %standard-phases
>>>   (add-after 'wrap 'prevent-local-package-interference
>>>     (lambda* (#:key outputs #:allow-other-keys)
>>>       (substitute* (string-append (assoc-ref outputs "out")
>>>                                   "/bin/<program-name>")
>>>         (("^#!/.*$" shabang)
>>>          (string-append shabang
>>>                         "export PYTHONNOUSERSITE=1\n"))))))
>
> That is indeed a simple thing we could do to harden Python binaries from
> picking up user pip-installed dependencies potentially causing
> problems.  I would welcome such a patch.
>

Perhaps, but if this is expected (and known) upstream behavior, I'm
wary of deviating from these expectations. This general area does seem
tricky and no simple best answer I guess.

>> Of course, it makes no sense to add such snippet to all definitions.
>> Instead, we could modify python-build-system to allow doing a similar
>> thing based on a flag passed in package's `(arguments)`.
>
> I think it need not be made configurable but just applied
> indiscriminately to the wrap phase used in the python-build-system.

And this is part of the same question then, we should try to be
consistent, yes. I don't see a clear right path, but I haven't thought
much about this area. I think it comes down to a current
issue/limitation/quirk of Python from upstream and packaging for our
distro puts us in between what comes from them and how to take care of
our users.

But we'll be rebuilding the Python world anyway, so now is a chance to
try out some changes like that, though maybe it is a bit much with
what we are trying already. See <https://issues.guix.gnu.org/63139>

John