Re: program prepared with `guix pack` unusable by end users

[Wojtek Kosior via <help-guix@gnu.org>]

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

> > IMHO yes, the pack output does not work as expected.  That's the
> > definition of a bug.  
> 
> I disagree.  That Python gives precedence to USERSITE compared to
> site-packages and GUIX_PYTHONPATH is by design, so that users can
> override system provided libraries such as those by Guix.  It used to be
> the other way around, and it caused all sort of problems such as
> virtualenv not working as expected on Guix.

Perhaps the best solution would be to
* have Python interpreter itself give precedence to user site packages but
* have user site disabled (or enabled with lower precedence) by default
  for Python applications.

Consider the creation of wrapper script for python programs as it is
done now[1]. Is there currently any application that would behave
incorrectly with PYTHONNOUSERSITE exported as 1 and
`~/.local/lib/python<PYTHON-VERSION>/site-packages/` included in
GUIX-PYTHONPATH after the other paths? If there is, perhaps it would be
at least easier to make a workaround for this single application?

[1] https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/python-build-system.scm?id=176a501360699581b49f19ffde1ea3bb6285b8be#n225

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #0: saint Albert Chmielowski
Poznaj świętych krakowskich!  #0: święty Albert Chmielowski
https://pl.wikipedia.org/wiki/Adam_Chmielowski
-- (sig_end)


On Thu, 27 Oct 2022 12:59:23 -0400
Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Hi,
> 
> Csepp <raingloom@riseup.net> writes:
> 
> > Wojtek Kosior via <help-guix@gnu.org> writes:
> >  
> >> [[PGP Signed Part:Undecided]]
> >> My problem has been solved. It turned out the Python interpreter
> >> contained within the pack was finding an older version of `hydrilla`
> >> Python package installed in `~/.local/lib/python3.9/site-packages` and
> >> that older version was missing the `console_scripts` entry point that
> >> was being loaded. It's worth mentioning that Python interpreter gives
> >> `~/.local/lib/python3.9/site-packages` priority over the paths that
> >> Guix adds to GUIX_PYTHONPATH.
> >>
> >> The solution was to patch the wrapper script for each of the commands
> >> my package provides. Definition of PYTHONNOUSERSITE enviroment variable
> >> stops Python from looking at local site packages.  
> 
> [...]
> 
> >> It's worth noting that this problem is not exclusive to `guix pack` or
> >> to my particular package. Users of other Python programs could in some
> >> circumstances experience similar issues. Which makes me think -
> >> shouldn't the default behavior be changed? Perhaps by making Python
> >> give paths from `GUIX_PYTHONPATH` priority over those in user site
> >> packages directory? Should I report this as a bug to bug-guix@gnu.org?
> >>
> >> Best,
> >> Wojtek  
> 
> [...]
> 
> > IMHO yes, the pack output does not work as expected.  That's the
> > definition of a bug.  
> 
> I disagree.  That Python gives precedence to USERSITE compared to
> site-packages and GUIX_PYTHONPATH is by design, so that users can
> override system provided libraries such as those by Guix.  It used to be
> the other way around, and it caused all sort of problems such as
> virtualenv not working as expected on Guix.
> 



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