Hi John, John Kehayias <john.kehay...@protonmail.com> writes:
> Hi, > > On Sat, Jul 01, 2023 at 11:57 AM, Maxim Cournoyer wrote: > >> Hi, >> >> Wojtek Kosior <kos...@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. While it's true that it's an intended upstream behavior, I think in the context of Guix users packages to be self-contained or in some case be able to load Guix-installed plugins or extensions, but here it seems reasonable that a Guix-packaged Python binary prefers loading Python libraries from Guix rather that from the Python user site. >>> 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> It's a simple change, I guess we could try it at the same time, if someone volunteers to do it! -- Thanks, Maxim