Re: PYTHONPATH issue explanation

[Ricardo Wurmus]

宋文武 <address@hidden> writes:

> Option 2, "GUIX_PYTHONHOME_X_Y" can not be used in the build-system
> unless we make a union of python inputs

For texlive we create a temporary union in the build system, so this
shouldn’t be an unsurmountable obstacle.

What I don’t like about this solution is that PYTHONHOME can only hold a
single directory, so composing profiles (that use the same Python
variant) would no longer work.  I prefer the
GUIX_PYTHON_X_Y_SITE_PACKAGES solution, because it is an actual search
path.

> - "GUIX_PYTHON_X_Y_SITE_PACKAGES" (X.Y is not a valid env identifier
>   in bash) is necessary for the "build" environment.
>
>   We don't make a union of all the inputs in the "build" environment, so
>   a PATH (contains multiples directories) like env have to be used to
>   let python find all its "site-packages" from inputs.

I think this might be a good solution as it is a drop-in replacement for
our current use PYTHONPATH.

Hartmut wrote this:

> - sys.prefix and sys.exec_prefix would still point to the store, not to
>   the profile.  This might break Python appications expecting
>   site-packages to be below sys.prefix.

Is this an actual problem?  Do you know of applications that make this
assumption?  If so, is this unfixable?

>   We have a union "profile" for all the python packages, so environment
>   variables can be totally avoided with the help of "venv".
>
>   > We could avoid GUIX-PYTHONHOME[23] if we stop resolving the symlinks
>   > at the correct point in iteration.
>
>   This is exactly what "venv" does!  We only need to make the "profile"
>   a "venv" for python.  For python3, a simple "pyvenv.cfg" file is
>   enough, for python2 I guess we have to make a union or copy files like
>   what "virtualenv" does.

I’m not too hopeful about this variant, but I’m rather ignorant about
venvs.  My main concern is about whether it will still be possible for
users to create venvs from a subset of their installed packages when we
generate a pyvenv.cfg by default.

> I plan to implement option 1 by adding a "sitecustomize.py" (better
> than modify "site.py") into the python packages, and modify
> "search-path-specification" to use "GUIX_PYTHON_X_Y_SITE_PACKAGES".
>
> How's that sound?

This sounds good to me.  Thank you and thanks again, Hartmut, for laying
out our options and analysing their advantages and drawbacks!

Before working on this, though, I would like to have the above question
answered to avoid wasting your time.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net