Hartmut Goebel <h.goe...@crazy-compilers.com> writes: > Hi, > > I agree with Ricardo: We first should agree on what we want to > implement.
Okay. > > 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 I have append some text, it's available to all in realtime? not sure how it works... > > 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. Yes, but if "GUIX_PYTHON_X_Y_SITE_PACKAGES" does works (i hope so) in the "profile" side, it's better to replace PYTHONPATH for consistent. > >> - 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. A workaround for the broke case maybe tell the user to create a "sitecustomize.py" in the created venv, and add the search paths of profile himself. I'd like do more tests with the GUIX_PYTHON_X_Y_SITE_PACKAGES option (patch sent), hope it works :-)
