Set PYTHONNOUSERSITE=1

[charles-turner-1]

Python docs

This flag removes ~/.local from path & stop the continual issues stemming from .local install's conflicting.

Tests show it won't prevent users from installing their own versions of packages when in a virtual environment:

(venv) [ct1163@gadi-login-04 ~]$ PYTHONNOUSERSITE=1 python -c "import sys; print(sys.path)"
['', '/g/data/xp65/public/apps/med_conda/envs/analysis3-25.05/lib/python311.zip', '/g/data/xp65/public/apps/med_conda/envs/analysis3-25.05/lib/python3.11', '/g/data/xp65/public/apps/med_conda/envs/analysis3-25.05/lib/python3.11/lib-dynload', '/home/189/ct1163/venv/lib/python3.11/site-packages']
(venv) [ct1163@gadi-login-04 ~]$ PYTHONNOUSERSITE=0 python -c "import sys; print(sys.path)"
['', '/g/data/xp65/public/apps/med_conda/envs/analysis3-25.05/lib/python311.zip', '/g/data/xp65/public/apps/med_conda/envs/analysis3-25.05/lib/python3.11', '/g/data/xp65/public/apps/med_conda/envs/analysis3-25.05/lib/python3.11/lib-dynload', '/home/189/ct1163/venv/lib/python3.11/site-packages']

[rbeucher]

What's the action on this?

[charles-turner-1]

We decided on using a separate package to scan the user site directories for stuff in .local and warn users, instead of forcing them to create a venv in order to use packages in .local.

That stalled because of some issues related to ipython initialisation.

I actually figured out what I think is a solution the other day whilst working on ACCESS-NRI/access-nri-intake-catalog#455.

I'll see if I can get the fixes in now.

[rbeucher]

Not a priority, I was just going through the issues.

[rbeucher]

Let me know when you have and update on this @charles-turner-1

[charles-turner-1]

I still haven't been able to figure out a way to reliably get the warning to print out in Jupyter notebooks, which is our main use case we need to hit.

Appears to be due to .pth files executing before ipython attaches. All very irritating and fiddly, I'll let you know when I do work it out.