This page describes both global and user command-line Python environments, and the Python environment available in the JupyterHub server web application. It does not address user-configured conda environments.
System and JupyterHub server Python versions
There are two versions of Python available on the command line ("system" Python) on BRCF compute servers. In Ubuntu 20.04, these versions and the command to invoke them are:
- 2.7 - python, python2
- 3.8 - python3, python3.8
(Note that the 3.x python version on Ubuntu 18.04 was 3.6.)
There are corresponding versions of pip that should be used to install 3rd party packages:
- for Python 2 - pip, pip2
- for Python 3 - pip3
Understanding Python add-on packages
Globally installed Python packages are available to any Python command-line environment of a compatible version. To see which Python packages are installed, along with their versions, use pip2 list or pip3 list. Similarly, user-installed packages can be viewed using pip2 list --user or pip3 list user. These user-installed packages are installed by default in the user's Home directory, in a directory with a name like ~/.local/lib/pythonN.N/site-packages, where N.N is the Python version.
Unlike the R environment, where user-installed packages are automatically visible to the RStudio Server running a compatible R version (see R and RStudio Server R versions), user-installed Python packages are not available in the JupyterHub server. This is because JupyterHub server packages are installed in a global anaconda environment that is only accessible to admin users. Thus JupyterHub packages must be installed by us, so contact us (rctf-support@utexas.edu) if there is a package you'd like to see installed.
Local/Global package installation conflicts
Globally-installed Python add-on packages may be updated during system maintenance. This can sometimes cause problems when users invoke Python tools, or load Python libraries, with many dependencies when some of the dependencies have been updated system-wide, but others have been locally installed and are not at a compatible level. The resulting error messages can be rather obscure, but typically show up after system maintenance has been performed.
To troubleshoot this possibility, move your local Python installation area out of the way. For example, for Python 3.8:
mv ~/.local/lib/python3.8 ~/.local/lib/python3.8.bak
If this produces a different error indicating that one or more locally installed packages are missing, the user can re-install them then see if the problem is resolved. Check the now-named ~/.local/lib/pythonN.N.bak/site-packages directory, where N.N is the Python version being used to see the packages that were locally installed previously. Even if this resolves the immediate issue, the user may later find that they need to re-install other packages that were previously installed locally.
Finally, if renaming the local Python installation directory does not resolve the issue, it may be an issue with the globally installed packages, so Contact Us.
Troubleshooting other JupyterHub server issues
In addition to the Local/Global package conflict issue described above, other issues can arise involving JupyterHub server (or less commonly, command-line Python). These browser and disk quota issues are similar to those seen for R, so see Troubleshooting R/RStudio server issues. If all else fails, submit a help request to our rctf-support@utexas.edu support email.