Hi Harmut! Hartmut Goebel <h.goe...@crazy-compilers.com> writes:
> Hi schrieb Maxim, >> Sorry for the delay. > > No problem, I reward this with another delay ;-) (Just kidding ;-) > > >> Hartmut Goebel <h.goe...@crazy-compilers.com> writes: >> >>> 2) This does not remove duplicates and does not honor .pth files in >>> the respective directories - which might still be used. Thus >>> site.addsitedir() should be called for adding the paths. This also >>> takes care about duplicates. >> I confess I didn't pay attention to .pth files, which mostly seemed like >> legacy cruft to me; are they still used in the context of PEP 517 and >> modern Python packaging? > > I can't tell for sure. (I rinember to have seen a note about .pth still > being used in some setuptool-tick, but can't find it now.) Anyhow, since > site.py still supports it, I would prefer to be on the save side and > support it, to. > >> The problem with calling site.addsitedir is >> that it simply appends to sys.path. We want to splice in the content of >> GUIX_PYTHONPATH at a controlled location. > > site.addsitedir takes an option second arguments where the paths are > collected into. > > >>> 4) Since PYTHONPATH is evaluated prior to importing sitecustomize, any >>> sitecustominze.py in the user's path will overwrite our file, thus >>> inhibiting our paths to be added. Not sure this is what we want in Guix. >> I asked guidance on the #python channel on freenode and was recommended >> to use sitecustomize.py for this purpose; reading the doc here seems to >> confirm our usage of it is as intended [0]: > > IC. > > >>> 6) Please add some more comments to the code explaining the idea. >> I was under the impression the code was concise enough to forego with >> verbose explanations; I'd rather keep it this way. > > Please add some comments. I had a hard time understanding it - and I was > not even sure I understood, see my question (1). I'm spread thin right now, so if you could prepare a patch addressing the above for me to review, that'd be much appreciated. Otherwise I'll get to it, but it won't be before some time. > Another point, which came into my mind just now: Do virtuall > environments still work as expected? (With --system-site-packages, > packages in the profile are available, but venv-packages overwrite. > Without ----system-site-packages packages in the profile are *not* > available.) Yes! This was the main motivation behind this change. Thank you, Maxim