Ludovic Courtès <l...@gnu.org> writes: > Rutherther <ruthert...@protonmail.com> skribis: > >> When I add both python and a python package (seems like any) to a >> relocatable guix pack, the resulting python in the merged profile seems >> to be broken. Specifically its `sys.path` contains missing paths.
> Commit d5e0180805f52ef38a03ff9d6c11dd6174e3526b fixed a similar issue I > think, discussed at <https://issues.guix.gnu.org/53258>. > > Not sure whether it’s a new problem here. Konrad, Maxim, Josselin, > WDYT? :-) This problem clearly looks like it's caused by our sitecustomize.py. One indicator is "When I add both python and a python package": if there is no additional package, only python by itself, our sitecustomize doesn't do anything. However, I don't see how the recent patch (see https://issues.guix.gnu.org/68241) could be responsible for this new problem. It should have happened before as well. Here is what sitecustomize.py does: 1. Collect the "site-packages" subdirectories of everything on $GUIX_PYTHONPATH. 2. Normalize them via sys.normpath() 3. Add them to sys.path 4. Re-arrange the elements in sys.path such that the add-on packages come before Python's standard library. The recent patch fixes a bug in the last step, which wasn't executed at all (and generated an error message). So the difference between the current and the previous behavior is only the order of entries in sys.path. The current problem is that even the standard library's paths are wrong. I suspect that this is due to sys.normpath not implementing the correct POSIX semantics for dot-dot. Cheers, Konrad.
