While we have installed a small number of highly-used packages to each version of Python, we encourage users to maintain their own Python packages. This ensures that the user has no discontinuity in their workflow waiting for packages to be installed and that packages work with the user's chosen, loaded Python version module. Python packages are built specifically to a version of Python and may not work properly if a different version of Python is loaded. For example, there is still a great disparity between Python 2 and Python 3. O2's "module" feature allows users to quickly and easily switch between Python versions.
Useful commands:
Command | Meaning | ||
|---|---|---|---|
| shows the versions of Python installed on O2 (requires | ||
| loads an individual module (substitute version for an actual version) | ||
| unloads an individual module | ||
| shows the current version of Python loaded | ||
| shows what packages are installed for currently loaded Python module |
Note that in order for module avail python to give any output, you must have gcc/6.2.0 loaded into your environment. Alternately, you can use module spider python to circumvent this, but you will still need gcc/6.2.0 loaded in order to load any python modules that are installed.
...
This behavior could arise for any number of reasons. The most common reason that RC sees is that you've forgotten to load the correct python module prior to activating your virtual environment. Because virtual environments (as configured on O2) are necessarily dependent on their source installations, it is required to load the python module from which you created that virtual environment before activating it, every time you use it. If you have made sure you have already done so, and in the correct order (load module THEN activate virtual environment), then please submit a ticket with as many details as possible (including terminal output and command history such that we know where your environment lives and how to replicate your issue) to rchelp@hms.harvard.edu.
Package mismatch errors with environments that use python/3.7.4
You may run into a problem where your environment detects a version of a package that lives in /n/app/python/3.7.4-ext and is unable to access/uninstall/upgrade/downgrade to a version that you desire. The quickest way to address this is to execute unset PYTHONPATH after loading the python/3.7.4 module but before activating your virtual environment. If you have personally modified the $PYTHONPATH variable for other purposes, you may need to re-populate it after removing the module package path from the variable (you can check if/how it is populated prior to executing unset by running echo $PYTHONPATH). If /n/app/python/3.7.4-ext/lib/site-packages is not the only path on $PYTHONPATH and unset-ing it is not worthwhile, you may choose to manually excise the path from the variable using whatever methods you find appropriate, though this is far less trivial than simply unset-ing it and repopulating it afterward, and we are unable to provide any general guidance to do so. If you require assistance with this sort of surgical modification of $PYTHONPATH, please contact us at rchelp@hms.harvard.edu and we can assist you with the process.