Site-packages not isolated from ~/.local

[frankier]

While trying to package https://github.com/lukas-blecher/LaTeX-OCR I ran into problems with the appimage finding packages from my ~/.local. In particular, transformers tried to import tensorflow and found a copy there, which caused problems. I noticed there is some attempt to isolate from system package so I thought I might file a bug here to discuss.

I'm not sure what the solution is here. One of the advantages of AppImage is the lack of isolation makes a lot of things easier. There are reasons people could want global site packages available, e.g. installing plugins. On the other hand, it can definitely cause things to interfere with each other.

What do you think? Perhaps there could be an option of site-packages isolation (no/weak/full) where weak is the current behavior, and full nukes the whole thing before adding stuff from the AppImage.

[niess]

Hello,

indeed.

Currently, only system packages are "isolated". This is done using a hook, sitecustomize.py. The clean_path function prunes sys.path at Python's initialisation. However, it leaves user packages in the path. The intent was that the AppImage behave as a "standard" Python runtime. Yet, there might be cases where this is problematic, e.g. for a standalone application due to conflicts with user packages.

Adding an option for this, as you suggested, sounds good to me. I am open to a PR if you feel like implementing this, e.g. by modifying sitecustomize.py. Otherwise, I might do it later on.

Concerning the implementation, I see two possibilities.

1. Package different sitecustomize.py files, depending on the isolation level selected when building the AppImage.
2. Add an env variable, e.g. PYTHONAPPIMAGE_ISOLATION, and set the isolation level at runtime in sitecustomize.py depending on the value of this variable.

[niess]

@frankier,

I just realized that Python already has such isolation option built in. Starting it with -sE results in ~/.local and PYTHONPATH not to be added to sys.path. The second option, -E might have some other effects though, since it says that it disables PYTHON env vars generally speaking, not only PYTHONPATH. See e.g. the CLI help:

-E     : ignore PYTHON* environment variables (such as PYTHONPATH)
-s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE

Thus, if you start your application with -sE, then you should have ''full'' isolation. Isn't it? See e.g. the tasmotizer example, started with -s.

I think that this is better than using env variables, because those might conlicts. For example, if an application calls another one, but they require different env vars as one is isolated but the other should not.

[frankier]

Thanks @niess . This seem to resolve my issue.