Hi, On Sat, Jul 01, 2023 at 11:57 AM, Maxim Cournoyer wrote:
> Hi, > > Wojtek Kosior <[email protected]> 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
