Hi, I agree with Ricardo: We first should agree on what we want to implement.
I created a pad at [1] for collecting all test-cases and the expected results. Please add you test-cases there. Thanks! [1] https://semestriel.framapad.org/p/guix-python-site-packages-test-cases Am 17.03.2018 um 02:41 schrieb 宋文武: > - "GUIX_PYTHON_X_Y_SITE_PACKAGES" […] is necessary for the "build" > environment. For the build environment we could easily work around using PYTHONPATH. Since the build-system is clearly defined and does not interfere with any user-definitions, this is save to do. > - Avoid any environment variable for the "profile" environment. > > We have a union "profile" for all the python packages, so environment > variables can be totally avoided with the help of "venv". […] > 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. This would be a very elegant solution. Unfortunately this does not work as shown in part 2 of my analysis, esp. point 4a. > > We could avoid GUIX-PYTHONHOME[23] if we stop resolving the symlinks > > at the correct point in iteration. > > This is exactly what "venv" does! Unfortunately venv works quite different: system site-packages are always taken from sys.base_exec. See part 3 of my analysis, esp. the "pyvenv.cfg" section. > 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". When implementing this in sitecustomize.py, you will end up re-implementing the complete venv mechanism. When going the GUIX_PYTHON_X_Y_SITE_PACKAGES route, we should look where the best place will be: Maybe site.PREFIXES, maybe site.getsitepackages(), maybe site.venv(). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
