> > 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/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 wrote: > Hi, > > Csepp writes: > > > Wojtek Kosior via 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. >