Hi, Csepp <raingl...@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-g...@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. -- Thanks, Maxim
