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

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

[edk]

Dear Guix devs,

While working around this bug:

https://issues.guix.gnu.org/63912

I found that guix's Python will load anything in
.local/lib/python3.10/site-packages/ over any installed package in the
current profile. This makes pip-installed package overshadow guix's.

I'm not sure this is desirable behavior. What I was expecting was for
the host system's python packages to be completely ignored. If I need to
change that, I can explicitely change GUIX_PYTHONPATH.

GUIX_PYTHONPATH is set to:
/home/edouard/.guix-profile/lib/python3.10/site-packages
/gnu/store/avgyacvy2n4x510dpwsf9dzadh7ldnd2-profile/lib/python3.10/site-packages
/home/edouard/.guix-profile/lib/python3.10/site-packages
/home/edouard/.guix-profile/lib/python3.9/site-packages
/home/edouard/.guix-profile/lib/python3.9/site-packages
/home/edouard/.guix-profile/lib/python3.9/site-packages
/home/edouard/.guix-profile/lib/python3.9/site-packages

Therefore loading packages from ~/.local/lib/python3.10/site-packages/
must be hardcoded in the interpreter.

Any thoughts ? Maybe it is a known problem ? If so, my apologies for the
noise.

Cheers,

Edouard.

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

[宋文武]

edk@beaver-labs.com writes:

> Dear Guix devs,
>
> While working around this bug:
>
> https://issues.guix.gnu.org/63912
>
> I found that guix's Python will load anything in
> .local/lib/python3.10/site-packages/ over any installed package in the
> current profile. This makes pip-installed package overshadow guix's.
>
> I'm not sure this is desirable behavior. What I was expecting was for
> the host system's python packages to be completely ignored.

Hello, I think this is a well-known issue according to PEP 668:
https://peps.python.org/pep-0668/

The suggested solution is to introduce a `EXTERNALLY-MANAGED` file to
disable the useage of `pip install`, and advice `guix shell` or `venv`.

Similiar to ArchLinux: https://gitlab.archlinux.org/archlinux/packaging/packages/python/-/commit/547eee4deb54fda2a3892997145b57de37301c5d

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

[Maxim Cournoyer]

Hi,

宋文武 <iyzsong@envs.net> writes:

> edk@beaver-labs.com writes:
>
>> Dear Guix devs,
>>
>> While working around this bug:
>>
>> https://issues.guix.gnu.org/63912
>>
>> I found that guix's Python will load anything in
>> .local/lib/python3.10/site-packages/ over any installed package in the
>> current profile. This makes pip-installed package overshadow guix's.
>>
>> I'm not sure this is desirable behavior. What I was expecting was for
>> the host system's python packages to be completely ignored.
>
> Hello, I think this is a well-known issue according to PEP 668:
> https://peps.python.org/pep-0668/

Agreed, I think this works as designed: the Guix-installed dependencies
appear as *system* dependencies on the sys.path (see 'python -m site'),
and USER_SITE (which is ~/.local/lib/python3.10/site-packages) must have
precedence over it for locally user-installed packages to be able to
override the system packages.

That's for example necessary for virtualenvs to work as designed (it
used to be that virtualenvs were near useless, with the Guix-provided
dependencies taking precedence on the ones installed in a virtualenv).

-- 
Thanks,
Maxim

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

[Wojtek Kosior via Development of GNU Guix and the GNU System distribution.]

[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]

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

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)`.

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Fri, 30 Jun 2023 23:13:55 -0400 Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Hi,
> 
> 宋文武 <iyzsong@envs.net> writes:
> 
> > edk@beaver-labs.com writes:
> >  
> >> Dear Guix devs,
> >>
> >> While working around this bug:
> >>
> >> https://issues.guix.gnu.org/63912
> >>
> >> I found that guix's Python will load anything in
> >> .local/lib/python3.10/site-packages/ over any installed package in the
> >> current profile. This makes pip-installed package overshadow guix's.
> >>
> >> I'm not sure this is desirable behavior. What I was expecting was for
> >> the host system's python packages to be completely ignored.  
> >
> > Hello, I think this is a well-known issue according to PEP 668:
> > https://peps.python.org/pep-0668/  
> 
> Agreed, I think this works as designed: the Guix-installed dependencies
> appear as *system* dependencies on the sys.path (see 'python -m site'),
> and USER_SITE (which is ~/.local/lib/python3.10/site-packages) must have
> precedence over it for locally user-installed packages to be able to
> override the system packages.
> 
> That's for example necessary for virtualenvs to work as designed (it
> used to be that virtualenvs were near useless, with the Guix-provided
> dependencies taking precedence on the ones installed in a virtualenv).
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Maxim Cournoyer]

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.

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

-- 
Thanks,
Maxim

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

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

[Maxim Cournoyer]

Hi John,

John Kehayias <john.kehayias@protonmail.com> writes:

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

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

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

[Wojtek Kosior via Development of GNU Guix and the GNU System distribution.]

[-- Attachment #1: Type: text/plain, Size: 4605 bytes --]

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

I just saw this message and hurried myself up to test the patch to
python-build-system that I made. Unfortunately, it turns out the
"PYTHONNOUSERSITE=1" env var breaks pip which tries to install wheels to
the system site directory and fails due to a read-only filesystem.

It seems we need to have this configurable on per-package basis, after
all. Should I try to make a patch which adds a build system argument
that controls this?

Also, the PYTHONNOUSERSITE variable only affects loading from the
actual site dir, not from virtualenvs (which rely on PYTHONPATH IIRC).
Should we try to add extra hardening to packages so that they are not
affected by virtualenvs either?

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Thu, 06 Jul 2023 11:35:15 -0400 Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Hi John,
> 
> John Kehayias <john.kehayias@protonmail.com> writes:
> 
> > 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.  
> 
> 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!
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Maxim Cournoyer]

Hi Wojtek,

Wojtek Kosior <koszko@koszko.org> writes:

>> > 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!
>
> I just saw this message and hurried myself up to test the patch to
> python-build-system that I made. Unfortunately, it turns out the
> "PYTHONNOUSERSITE=1" env var breaks pip which tries to install wheels to
> the system site directory and fails due to a read-only filesystem.

I'm not sure I follow; why would PYTHONNOUSERSITE affect pip?  I thought
it should only appear in wrappers of Python executables, not be set in a
profile's environment (thus not affecting pip) ?

Could you share the diff of the patch you tried so far?

-- 
Thanks,
Maxim

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

[Wojtek Kosior via Development of GNU Guix and the GNU System distribution.]

[-- Attachment #1.1: Type: text/plain, Size: 1462 bytes --]

> > I just saw this message and hurried myself up to test the patch to
> > python-build-system that I made. Unfortunately, it turns out the
> > "PYTHONNOUSERSITE=1" env var breaks pip which tries to install wheels to
> > the system site directory and fails due to a read-only filesystem.  
> 
> I'm not sure I follow; why would PYTHONNOUSERSITE affect pip?  I thought
> it should only appear in wrappers of Python executables, not be set in a
> profile's environment (thus not affecting pip) ?

Indeed. And once I make my change, PYTHONNOUSERSITE gets also placed in
the wrapper of the `pip` executable.

> Could you share the diff of the patch you tried so far?

I am attaching the patch file.

I was trying to test with

    ./pre-inst-env guix shell -C --network --no-cwd python-xmldiff coreutils python-pip
    pip install xmldiff==2.4
    echo > ~/.local/lib/python3.10/site-packages/xmldiff/main.py
    xmldiff --help

Without my patch, we get an error on 4th line. With my patch, we get
the "Read-only file system" error on the 2nd line

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-guix-build-python-build-system-Don-t-process-user-si.patch --]
[-- Type: text/x-patch, Size: 1903 bytes --]

From 6c2cd9679d52ac4f06e91026948da5fae2c2a29c Mon Sep 17 00:00:00 2001
Message-Id: <6c2cd9679d52ac4f06e91026948da5fae2c2a29c.1688740423.git.koszko@koszko.org>
From: Wojtek Kosior <koszko@koszko.org>
Date: Mon, 3 Jul 2023 10:53:41 +0200
Subject: [PATCH] guix: build: python-build-system: Don't process user site dir

* guix/build/python-build-system.scm (wrap): Define PYTHONNOUSERSITE for
programs so they don't incorrectly pick up local, pip-installed libraries.
---
 guix/build/python-build-system.scm | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/guix/build/python-build-system.scm b/guix/build/python-build-system.scm
index aa04664b25..bbcb861da0 100644
--- a/guix/build/python-build-system.scm
+++ b/guix/build/python-build-system.scm
@@ -241,12 +241,16 @@ (define* (wrap #:key inputs outputs #:allow-other-keys)
   (define %sh (delay (search-input-file inputs "bin/bash")))
   (define (sh) (force %sh))
 
-  (let* ((var `("GUIX_PYTHONPATH" prefix
-                ,(search-path-as-string->list
-                  (or (getenv "GUIX_PYTHONPATH") "")))))
+  (let* ((var-pythonpath `("GUIX_PYTHONPATH" prefix
+                           ,(search-path-as-string->list
+                             (or (getenv "GUIX_PYTHONPATH") ""))))
+         ;; Harden applications by preventing Python from automatically
+         ;; picking up libraries in user site directory.
+         (var-usersite '("PYTHONNOUSERSITE" = ("1"))))
     (for-each (lambda (dir)
                 (let ((files (list-of-files dir)))
-                  (for-each (cut wrap-program <> #:sh (sh) var)
+                  (for-each (cut wrap-program <> #:sh (sh)
+                                 var-pythonpath var-usersite)
                             files)))
               bindirs)))
 

base-commit: 08649cfcd41bc78ba4df0609798461816dda9496
-- 
2.40.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Maxim Cournoyer]

Hello,

Wojtek Kosior <koszko@koszko.org> writes:

>> > I just saw this message and hurried myself up to test the patch to
>> > python-build-system that I made. Unfortunately, it turns out the
>> > "PYTHONNOUSERSITE=1" env var breaks pip which tries to install wheels to
>> > the system site directory and fails due to a read-only filesystem.  
>> 
>> I'm not sure I follow; why would PYTHONNOUSERSITE affect pip?  I thought
>> it should only appear in wrappers of Python executables, not be set in a
>> profile's environment (thus not affecting pip) ?
>
> Indeed. And once I make my change, PYTHONNOUSERSITE gets also placed in
> the wrapper of the `pip` executable.
>
>> Could you share the diff of the patch you tried so far?
>
> I am attaching the patch file.
>
> I was trying to test with
>
>     ./pre-inst-env guix shell -C --network --no-cwd python-xmldiff coreutils python-pip
>     pip install xmldiff==2.4
>     echo > ~/.local/lib/python3.10/site-packages/xmldiff/main.py
>     xmldiff --help
>
> Without my patch, we get an error on 4th line. With my patch, we get
> the "Read-only file system" error on the 2nd line

Neat!  I think maybe we could add a build argument called
e.g. '#:honor-user-site?' to disable the having PYTHONNOUSERSITE=1 in
the wrapper for a few select packages (e.g. pip, virtualenv, probably a
few others that are expected to work with or honor pip user-installed
Python packages).

-- 
Thanks,
Maxim

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

[Wojtek Kosior via Development of GNU Guix and the GNU System distribution.]

[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]

> I think maybe we could add a build argument called
> e.g. '#:honor-user-site?' to disable the having PYTHONNOUSERSITE=1 in
> the wrapper for a few select packages (e.g. pip, virtualenv, probably a
> few others that are expected to work with or honor pip user-installed
> Python packages).
> 

I just did[1] this (with some new developments described in the cover
letter). As this was my first attempt at sending patches to Guix,
please forgive my mistakes :)

Best,
Wojtek

[1] https://issues.guix.gnu.org/64573

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Sat, 08 Jul 2023 01:08:30 -0400 Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Hello,
> 
> Wojtek Kosior <koszko@koszko.org> writes:
> 
> >> > I just saw this message and hurried myself up to test the patch to
> >> > python-build-system that I made. Unfortunately, it turns out the
> >> > "PYTHONNOUSERSITE=1" env var breaks pip which tries to install wheels to
> >> > the system site directory and fails due to a read-only filesystem.    
> >> 
> >> I'm not sure I follow; why would PYTHONNOUSERSITE affect pip?  I thought
> >> it should only appear in wrappers of Python executables, not be set in a
> >> profile's environment (thus not affecting pip) ?  
> >
> > Indeed. And once I make my change, PYTHONNOUSERSITE gets also placed in
> > the wrapper of the `pip` executable.
> >  
> >> Could you share the diff of the patch you tried so far?  
> >
> > I am attaching the patch file.
> >
> > I was trying to test with
> >
> >     ./pre-inst-env guix shell -C --network --no-cwd python-xmldiff coreutils python-pip
> >     pip install xmldiff==2.4
> >     echo > ~/.local/lib/python3.10/site-packages/xmldiff/main.py
> >     xmldiff --help
> >
> > Without my patch, we get an error on 4th line. With my patch, we get
> > the "Read-only file system" error on the 2nd line  
> 
> Neat!  I think maybe we could add a build argument called
> e.g. '#:honor-user-site?' to disable the having PYTHONNOUSERSITE=1 in
> the wrapper for a few select packages (e.g. pip, virtualenv, probably a
> few others that are expected to work with or honor pip user-installed
> Python packages).
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]